-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
revise .' deprecation message and add related TODOs to base/deprecated.jl #25463
Conversation
src/julia-syntax.scm
Outdated
"context: If `A.'` appears in a multiplication, " | ||
"left-division, or right-division operation that " | ||
"was formerly specially lowered to an `A_mul_B`-like " | ||
"call, then the lazy `Tranpose(A)` is the correct " | ||
"call, then the lazy `tranpose(A)` is the correct " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tranpose
-> transpose
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. Thanks! :) (Also added a [ci skip]
.)
Does this message really need to be so dang long? I think users would be just fine with:
|
On the one hand I sympathize with the desire to make this message short. On the other hand I feel the complete information is useful. (Absent discussion of the eager->lazy transition and lowering change, whether To both keep this message short and provide the aforementioned guidance, one could direct the user to a complete news entry from the message. That approach seems reasonable, though I worry about adding extra hoops (needing to locate NEWS.md and search for the appropriate entry) that a substantial fraction of users may either jump through but be frustrated by or not jump through and then be frustrated when rewrites don't work as desired. The expected volume of frustration with the additional hoops struck me as greater than the expected volume of frustration with a long deprecation message, so I went with the latter. (I wrote this deprecation message rapidly, and imagine we can tighten it up a bit without losing much if any content besides.) Thoughts? Thanks! :) |
(Independent of how the deprecation message should be more extensively revised, I favor not coupling these fixes to those more extensive revisions, if agreeable :).) |
That's fair. I'll propose a simplification separately. |
Thanks all! :) |
This pull request revises the
.'
deprecation message in accord with changes in #25364 and #25461, and adds.'
-deprecation related TODOs to base/deprecated.jl's 0.7 section. Best!