-
Notifications
You must be signed in to change notification settings - Fork 205
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
Replace current "@required this.name" in the named parameters with "this.name!" #1103
Comments
The current In Anyway, I think |
The Replacing the foo({int someFunction(int)?!}) => ... (Granted, nullable required parameters are probably going to be rare enough that So, what would it look like otherwise? void foo({required int bar, required Map<String, String>? baz, required int qux(int value)}) => ...
//vs
void foo({int bar!, Map<String, String>? baz!, int qux(int value)!}) => ... Neither is particularly readable. I think I'd prefer a prefix in general, because suffixes are too easy to miss. void foo({int !bar, Map<String, String>? !baz, int !qux(int value)}) => ...
// or
void foo({!int bar, !Map<String, String>? baz, !int qux(int value)}) => ... (the former more than the latter). There is definitely room for improvement in Dart parameter syntax. I'd personally prefer a complete overhaul to just twiddling with a single word. |
void foo({@required int bar, @required Map<String, String>? baz, @required int qux(int value)}) => ...
//vs
void foo({int! bar, Map<String, String>?! baz, int! qux(int value)}) => ...
//or
void foo({int! bar, Map<String, String>! baz, int! qux(int value)}) => ... It's not me who invented question mark "suffixes" (for nullability purposes), I'm just using the same "API" to replace the meta-tag "@required" |
Being required is not part of the type, and the (For the last parameter, it would still go after the void foo({int! bar, Map<String, String>?! baz, int qux(int value)!}) => ... That's where the type ends and the |
No, the void foo({int! bar, Map<String, String>?! baz, int! qux(int value)}) => ...
//or
void foo({int! bar, Map<String, String>! baz, int! qux(int value)}) => ... |
The void foo({int! bar, Map<String, String>?! baz, int qux(int value)!}) => ... is placing the |
I'm not sure that the I thought it's done like that: void foo({int bar, Map<String, String> baz, Function qux}) => ... |
Dart has two ways to specify function-typed parameters: a prefix void f({int Function(int) callback});
void g({int callback(int value)}); Both work, and when you need make then nullable for null-safety, you do it as: void f({int Function(int)? callback});
void g({int callback(int value)?}); where the |
I propose this issue be updated to I think 👍 👎 Null is certainly proximal to required conceptually, but isn't the same, potentially making 👍 Devs already know how to handle different symbol meaning in different contexts ( 👎 However, IMO this would collide conceptually with 👎👎 Having multiple valid syntax elements with the same meaning creates noise and potential frivolous style arguments that dart has carefully avoided until now. The last point is IMO a big issue for this proposal unless the entire community wants One alternative approach could be to tackle this pain point at the editor level: configurably auto-fill |
@tatumizer asterisks are also popularly used to designate pointers, so it'd probably be best to avoid that confusion. @manyopensource I don't really see the benefit of using an already widely-used punctuation mark (that many people want to extend to have even more meanings) to replace a word that says what you mean. Pretty much every IDE can save you a few characters by offering As @munificent pointed out, while some view
You're kinda just saying that we're already used to punctuation instead of words, but it's different here. For both
That is a lot of effort an confusion just to avoid a keyword which, again, clearly states its purpose. There's no reason to omit it since it's not confusing and not ambiguous. Sure it's a few more characters but using Also, see https://xkcd.com/1306/, especially the alt-text: "The cycle seems to be 'we need these symbols to clarify what types of things we're referring to!' followed by 'wait, it turns out words already do that.'" |
@Levi-Lesches I kinda see your punctuation-as-control, but I meant that point more as a response to " I made an SDK issue for my auto-fill proposal: dart-lang/sdk#48119. I think you're mostly responding to the rewrite extension – I get why that'd be more controversial. However, having the option to let the machine fill in
Every |
This features is simple, understandable and requires less time to make changes!
Instead of this
We will have this
Thanks!
The text was updated successfully, but these errors were encountered: