Displaying a rounded rectangle isn't working?

I wanted to ask somewhen what is the difference between import and using, but I thought that it is something related to VC and that I use eclipse and don't use type checking I resigned.

Now I know and still happy not using type checking :-)

typechecking is not that bad tbh, it can catch bugs if you use it correctly. But it also adds a lot of text to your code. I dislike it in that way that you need to specify what an array contains, eg if you do 

var array = dict.keys();

// you need to do

var array = dict.keys as Array<Symbol>

//If you output multiple things in a function:

function foo() as Array<Numeric or String> {
   return [ 1, "foo" ];
}

I use it with level 1, so the array thing is a warning, but I don't want to ignore warnings, so I had to fix them. But it annoyed me, because I wanted them for typechecking my functions params.

No memory savings, no performance increasing, more text to write and won't help if Garmin will forget to add ANNOTATION somewhere if something can/can't be null...

Huge wasting of time.

It prevents stuff like this:

function yada(z as String, x as String) {
  return z + x;
}

yada(1,2) // without type checking would be 3
yada(1,2) // with: error from the compiler
yada("Works ", "for me") // yay

// This is being caught by the  type checking
ERROR: fenix6xpro: /home/ciq/src/source/t/typechecking.mc:15: Invalid '$.Toybox.Lang.Number' passed as parameter 1 of type '$.Toybox.Lang.String'.
ERROR: fenix6xpro: /home/ciq/src/source/t/typechecking.mc:15: Invalid '$.Toybox.Lang.Number' passed as parameter 2 of type '$.Toybox.Lang.String'.
ERROR: fenix6xpro: /home/ciq/src/source/t/typechecking.mc:17: Invalid '$.Toybox.Lang.Number' passed as parameter 1 of type '$.Toybox.Lang.String'.
ERROR: fenix6xpro: /home/ciq/src/source/t/typechecking.mc:17: Invalid '$.Toybox.Lang.Number' passed as parameter 2 of type '$.Toybox.Lang.String'

I'm not opposed to it.

The complaining about stuf like this tho...

WARNING: fenix6xpro: /home/ciq/src/source/models/Profiles.mc:31: Cannot determine if container access is using container type.

Where you need to solve it like this:

return { :id => id, :name => (self.profiles.get(id) as Array<String>)[0] };

1.I know usually  what types need in function call.

2. Name of parameters and name of function can say everything of type.

3. any errors  is showed immediately.

so still wasting of time :-)

Today I have an error firm ERA on venu

function foo(flags)

{

   flags &= mFlags;// error unhandled  exception

}

mFlags = 8;

var x = foo(4);

So is better to focus to fix bug, performance, optimizing other important thing instead of giving useless features.

Just because you don't like it/use it doesn't mean it is useless. I think it serves some purpose, perhaps the Garmin devs use it internally for their apps and enabled it for us as well.

I'm not against it, but it has some rough edges that need to be resolved.

Type checking actually first came out in April 2021.  Here's the intro:

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/the-road-to-strict-typing-is-paved-with-good-intentions

waterkip said:

I'm not against it, but it has some rough edges that need to be resolved.

My hot take: like a lot of Garmin things, the concept is ok, but the design and implementation leave something to be desired. I use typescript on a daily basis, and the difference is like night and day.

Like dc.fillPolygon() requires a use of a cast to a nested array type (Array<Array<Numeric>>), but the Monkey C parser doesn't recognize any types nested more than 2 levels deep (e.g. Array<Numeric> is as deep as you can go.)

Given that the documentation for fillPolygon tells you it takes a type that you're not even allowed to cast to (without a workaround) but the current state of Monkey Types is that you *have* to cast to it, this is a ridiculous bug:

https://developer.garmin.com/connect-iq/api-docs/Toybox/Graphics/Dc.html#fillPolygon-instance_function

fillPolygon(pts as Lang.Array<Lang.Array<Lang.Numeric>>) as Void

It's bad enough that the explicit cast is necessary in the first place. And there's the other issue that there's no error or warning for explicit casts between incompatible types, which means that it's very easy to accidentally subvert the type checker. Overuse of unsafe explicit casts is worse than having no type checking at all imo, because you gain a false sense of security.

I'm sure most of the various bugs will be fixed at some point, but I'm not sure about any design issues.

_psx_ said:

useless features

Typescript actually helps me and other devs write better javascript code (don't know if I can say the same for Monkey Types, yet). OTOH, there are definitely times when it can be worse than useless, like when you manually define types that come over the wire, but you define them wrong due to incorrect assumptions. Then you have the same issue of having a false sense of security -- i.e. "this code can't possible crash!!!1!" (but it does). I realize the audience and dev resources behind typescript massively outweigh that of Monkey C, but there's really nothing preventing Garmin from copying or mimicking some of the better features of more popular languages.

Same with waterkip's feature request for specifying barrel versions in an inexact way (like "use any version > 0.0.5"). This is the kind of thing that could've been copied from npm.

I also don't think it's a great design decision that "as" is used for both type casts and declarations. I feel like we've already seen instances where the two concepts have been confused by devs new to type checking, where type declarations *and* casts are used everywhere, but the overuse of casts means their app actually has no type safety. Every popular typed language I've used has different syntax for a type declaration vs a type cast, although it's possible there's some example I've missed.