You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
use blockquote syntax for existing messages — i.e. put > before everything that isn't a header. The reason for this is that we can provide excessive detail immediately below the blockquote, but (for example) only show it in the docs. It also enables...
...overloads. In a few cases we have situations like 'did you mean ?' — short of inventing a convoluted new syntax this sort of thing is trickier to accommodate in markdown. But I think we could get the same benefits by overloading messages — if we have something like this...
## some_error_code> This is the first message: %message%> This is the second message: %message%. It has additional details: %details%
This is a long-winded explanation of the two shorter messages above; it does not have parameters, and will be used in the docs
...then we could choose which summary message to use based on the function arity. The alternative is to continue having multiple error/warning codes for these situations, but that kinda sucks
sort out the messages themselves — there's lots of weird codes, messages that could be improved, duplicative stuff and so on
add them to the docs
The text was updated successfully, but these errors were encountered:
Describe the problem
Just jotting down a few thoughts on follow-ups to #11294, #11302, #11303 and #11304:
finish porting all runtime errors
use blockquote syntax for existing messages — i.e. put
>
before everything that isn't a header. The reason for this is that we can provide excessive detail immediately below the blockquote, but (for example) only show it in the docs. It also enables......overloads. In a few cases we have situations like 'did you mean ?' — short of inventing a convoluted new syntax this sort of thing is trickier to accommodate in markdown. But I think we could get the same benefits by overloading messages — if we have something like this...
...then we could choose which summary message to use based on the function arity. The alternative is to continue having multiple error/warning codes for these situations, but that kinda sucks
sort out the messages themselves — there's lots of weird codes, messages that could be improved, duplicative stuff and so on
add them to the docs
The text was updated successfully, but these errors were encountered: