Language: Replace current "@required this.name" in the named parameters with "this.name!"

Created on 20 Jul 2020  路  8Comments  路  Source: dart-lang/language

This features is simple, understandable and requires less time to make changes!

Instead of this

class Message {
  String id;
  String content;

  Message({@required this.id, @required this.content});
}

We will have this

class Message {
  String id;
  String content;

  Message({this.id!, this.content!});
}

Thanks!

feature

Most helpful comment

The required is for any named parameter, not just initializing formals (this.something in a constructor parameter list).

Replacing the required prefix with a ! suffix is unlikely.
This use of the syntax means something different from suffix ! in other places (non-null assertion). Also, it's easy to overlook and works badly with nullable function parameters like:

foo({int someFunction(int)?!}) => ...

(Granted, nullable required parameters are probably going to be rare enough that ?! would be the proper exclamation when seeing them).

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.
Even prefix ! works better for me:

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.

All 8 comments

The current @required is a annotation, not a keyword, so it is more associated with the meta library and the linter than with the language.

In nnbd it won't be a annotation anymore, but a real keyword instead (required).

Anyway, I think ! will cause confusion, specially considering that it is a operator already used when you want to tell the compiler to ignore some null-safety checkings.

The required is for any named parameter, not just initializing formals (this.something in a constructor parameter list).

Replacing the required prefix with a ! suffix is unlikely.
This use of the syntax means something different from suffix ! in other places (non-null assertion). Also, it's easy to overlook and works badly with nullable function parameters like:

foo({int someFunction(int)?!}) => ...

(Granted, nullable required parameters are probably going to be rare enough that ?! would be the proper exclamation when seeing them).

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.
Even prefix ! works better for me:

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.

@lrhn

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 ? is unrelated to being required. You can have non-nullable optional parameters and nullable required parameters, so it's not a given that the ! should go there, but it obviously can.

(For the last parameter, it would still go after the ), so:

void foo({int! bar, Map<String, String>?! baz, int qux(int value)!}) => ...

That's where the type ends and the ? goes for nullable function parameters.

No, the ! goes where the ? should go:

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 ? does not go on the int of int qux(int value) when the parameter is nullable.
An int? qux(Int value) means that the return type of the function parameter is nullable, not that the parameter itself is, so the ! would also have to be placed after the (int value). So:

void foo({int! bar, Map<String, String>?! baz, int qux(int value)!}) => ...

is placing the ! where the ? would go for the parameter type.

I'm not sure that the int qux(int value) is even legit as a named parameter! What is this - are you defining a function there? If so okay!

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 Function-based type and an infix C-like notation:

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 ? goes after the "end of the type", which is after the end of the parameters.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

eernstg picture eernstg  路  5Comments

leafpetersen picture leafpetersen  路  3Comments

stategen picture stategen  路  4Comments

moneer-muntazah picture moneer-muntazah  路  3Comments

wytesk133 picture wytesk133  路  4Comments