Show real type names in error messages
See original GitHub issueIn #4323 I was concerned about writing incorrect names for types in error messages.
Writing Expr’ in the error seems a (separate?) bug:
15 | case (IExpr(i1), IExpr(i2)) => IExpr(i1 + i2)
| ^^^^^^^^^^^^^^
| found: Expr.IExpr
| required: Expr'[T]
|
| where: Expr is a object
| Expr' is a trait
because it’s false that “Expr'
is a trait”. A bit better would be:
| where: Expr refers to object Expr
| Expr' refers to trait Expr
But even better would be to have a clearer syntax for these “footnotes”, something where the annotation is more clearly separate from the Scala syntax. For instance, if we use @
(which is reserved and can’t be used in types, I think):
| where: Expr@1 refers to object Expr
| Expr@2 refers to trait Expr
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:5 (5 by maintainers)
Top Results From Across the Web
How to display Sequelize validation error messages in ...
I tried your same validation on my local project on firstName field and I could get sequelize error like this console.log('err.name', ...
Read more >9 Error messages | The tidyverse style guide
9 Error messages. An error message should start with a general statement of the problem then give a concise description of what went...
Read more >Video: Input and error messages - Microsoft Support
On the Input Message tab, check the box next to Show input message when cell is selected. Type a Title if you want....
Read more >A story told by Type Errors - Dmitrii Kovanikov
In this blog post I'm going to show that using custom type errors is a simple task. I will present a lot of...
Read more >Custom error messages in JSON Schemas for Ajv validator
Property names can be used in error messages with the relative JSON-pointer (e.g. 0# ). Example: const schema = { type: "object", ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Import renaming also seems unconvincing, but again, we shouldn’t write that Expr1 isn’t an object, because that object is called Expr. I’d say that Expr1 isn’t an object.
I agree with Unicode subscripts are better if we can rely on Unicode, since they’re not allowed in Scala.
Which we probably often can. Otherwise,
Expr@1
was the best idea I had within ASCII after skimming https://stackoverflow.com/a/7657692, but I’m not sure it’s much better.We can also have a longer description such as “Expr1 is an object in package foo.bla.baz”. I just dislike using import renaming to express this. Note that import renaming is not enough anyway because some types do not have a stable path, e.g.:
Here’s the error Dotty outputs currently: