Change Foo:Class representation of Class types to Foo.class #6439
Conversation
Using the Foo.class representation of class types in error messages matches the type syntax used to write these types, instead of using a special and confusing syntax unique to compiler error messages. For example: class variable '@@foo' of Bar must be Hash(Thing:Class, String), not Hash(Thing, String) becomes class variable '@@foo' of Bar must be Hash(Thing.class, String), not Hash(Thing, String) which means the type is now represented exactly the same way in the error messages as source code.
| @@ -38,7 +38,7 @@ end | |||
|
|
|||
| class Crystal::Call | |||
| def raise_matches_not_found(owner, def_name, arg_types, named_args_types, matches = nil, with_literals = false) | |||
| # Special case: Foo+:Class#new | |||
| # Special case: Foo+.class#new | |||
There was a problem hiding this comment.
This is not exactly source code syntax, but it looks as if...
There was a problem hiding this comment.
The + syntax is a different issue. This is closer and so an improvement.
|
Just an idea: Java uses generics |
|
@straight-shoota but that would require changing the whole language, this is just about changing the error messages / string representation inside the compiler to be more consistent with the existing syntax. |
|
I wasn't suggesting to change the language. Just an idea though. This PR is certainly an improvement 👍 |
|
@asterite is there any reason this was like this in the first place? |
|
Ruby |
|
This is a small but an important improvement over the current behavior. Just this week alone I had to explain why the compiler error had |
Using the Foo.class representation of class types in error messages matches the
type syntax used to write these types, instead of using a special and confusing
syntax unique to compiler error messages.
For example:
becomes
which means the type is now represented exactly the same way in the error
messages as source code.