Edit Sound Parameter Types example in 'The Dart type system'

[bardes]

Page URL

https://dart.dev/language/type-system#use-sound-parameter-types-when-overriding-methods

Page source

https://github.com/dart-lang/site-www/tree/main/src/language/type-system.md

Describe the problem

The example in the section about sound parameter types when overriding methods seems weird. Wouldn't the problem be a cat not chasing the alligator?

Expected fix

Change the example to refer to a cat that refuses to chase anything but mouses.

Additional context

No response

[msaad7777]

I want to contribute to this project, can I have any issue assigned ?

[MaryaBelanger]

@bardes I'm not quite sure what this is trying to say either. It seems (like you said) if you were to tighten the parameter to the Mouse subtype, that would mean a cat would definitely not be able to take any parameter besides a Mouse type for its chase method. But the following example ("This code is not type safe because it would then be possible to define a cat and send it after an alligator") seems to imply that tightening the chase parameter to Mouse would allow it to chase an Alligator type? Or maybe it's saying that, if you were allowed to tighten parameter types, then that would allow you to override the type to something nonsensical (like an Alligator type)? But why that is not type safe is still unclear.

@sfshaza2 I see you wrote this years ago, do you think you could explain how tightening the chase parameter type to mouse is related to taking an Alligator type parameter? Or, just why tightening is not type safe? (If it was too long ago I can ask some engineers, lmk!).

I think the sentence "This code is not type safe because it would then be possible to define a cat and send it after an alligator:" needs to more clearly define why tightening is not type safe, without using the example as part of the definition since the example is arbitrary anyway. Like, "This code is not type safe because it would then be possible to...(?)"

[MaryaBelanger]

@msaad7777 anyone is welcome to contribute, just leave a comment on the issue you're interested in so we know someone is working on it, and open your PR. I would skip this one for now though, just because I'm not sure what should be done. If you're confident in your fix though, give it a try! Thanks!

[eernstg]

Drive-by comment. ;-)

I think the section 'Use sound parameter types when overriding methods' makes sense if considered in the context of Dart 1. With recent versions of Dart the second half just doesn't make sense:

The HoneyBadger example says that a contravariant position (a formal parameter type) can be overridden using a supertype (a parameter of type Animal is overridden by a parameter of type Object). No problems here. The reference to information about covariant parameters is fine, too.

However, the Cat example is confusing: I wouldn't expect example code which is a plain compile-time error to be of interest ("don't do this" doesn't make sense if we can't do it), and the code block includes the word 'warning' even though it's a compile-time error.

Next, the text says 'This code is not type safe', but it isn't relevant whether or not any given text is "type safe" when it can't be compiled in the first place.

If it's OK, style-wise, to talk about code which is a compile-time error then perhaps the following could work:

• Change 'static analysis: error/warning' to 'static analysis: error'
• Change 'This code is not type safe' to 'This code is rejected by the compiler'

It looks like there are many other source code snippets with 'static analysis: error/warning'. My immediate impression is that the 'warning' part hasn't been correct since Dart 1, but they should in any case be double checked.