The property type is not checked when I use ?? operator to set a value

[noti0nS]

Hello guys! I don't know if it's a intentional behavior, but for me it's so strange that I think that's a bug.
Basically the property "total" is a double, but in the fromMap method I'm able to set a empty string if map['total'] is null. This probably works at compile-time because the "map" has dynamic subtypes, but since I'm using the null checker I think the right behavior is the compiler doesn't allow the string be defined in case of the value being null.
And yes, at runtime it's breaks.

[jakemac53]

The problem here is indeed dynamic. I am not sure how much could be done here but maybe people have some ideas :).

Fwiw typing the map as Map<String, Object?> will prevent you from doing this.

Or you can more generally enable this in your analysis_options.yaml file, which I would also highly recommend:

analyzer:
  language:
    strict-casts: true

[noti0nS]

Thanks for answer @jakemac53 !

I didn't knew the 'strict-casts' option. It's really cool! 😁
But in this way I'll need make a cast explicitly every time I try get a value from a map. The point it's for me is strange I see the attribute asking a type of value and the ?? operator doesn't check the value on the right to check if it's ok in case the left value be null.

I think would be a nice feature because It's really common see the people use this pattern around the projects. But it's just a suggestion anyway 🙂

[jakemac53]

The point it's for me is strange I see the attribute asking a type of value and the ?? operator doesn't check the value on the right to check if it's ok in case the left value be null.

Yeah, I definitely see how that is confusing. Afaik the reason this isn't caught is because it is only the type of the entire expression that is checked against the LHS. That type is the least upper bound of dynamic and String, which is just dynamic. Then we check if dynamic is assignable to double which it is (without strict_casts enabled). So it is allowed.

I think to catch this type of problem would require pushing that lhs type "down" into the expression which would presumably be a large change to how the type system works today (and it probably isn't done that way for other, good reasons?). But maybe somebody else can chime in to that effect, I am not a type system guy haha.

dynamic is handy, but it really should be avoided wherever possible, imo. It causes all kinds of problems like this. I would remove it from the language entirely if I had the choice 😁.

[leafpetersen]

I think to catch this type of problem would require pushing that lhs type "down" into the expression which would presumably be a large change to how the type system works today (and it probably isn't done that way for other, good reasons?). But maybe somebody else can chime in to that effect, I am not a type system guy haha.

It's not terribly complex, but it would likely be a reasonably substantial breaking change. This is currently tracked as a part of a larger set of related changes that we might consider making here. cc @stereotype441

I'm going to close this issue in favor of that issue unless there is something specific we want to track here.