0

In Visual Studio Code, no errors seem to arise when an @required parameter is omitted when invoking a Dart function. Do I have to do something to get the analyzer working? Or are errors being flagged and I'm just not seeing them? Any help would be appreciated ...

import 'package:meta/meta.dart';

void sayHello({@required String to, bool inEnglish}){

  if(inEnglish == null || inEnglish){
    print("Hello, $to");
  } else {
    print("Bonjour, $to");
  }
}

main(){
 sayHello(inEnglish: true); // output: Hello, null, no complaints about **to** missing
}
Michael Rogers
  • 1,318
  • 9
  • 22

1 Answers1

2

Update

As of Dart 2.12, the required keyword replaces the @required meta annotation. For detailed info look into the official FAQ.

Original answer

The Dart language has required positional parameters, optional positional parameters, and optional named parameters. Sadly, Dart has no support for required named parameters.

The @required annotation doesn't actually do anything. It's just a workaround added by Flutter that the analyzer can use to add a warning when you don't pass a parameter that is marked with it. But it won't prevent you from omitting the "required" parameter, and code that does so will still compile and run perfectly well.

devrobf
  • 6,973
  • 2
  • 32
  • 46
Abion47
  • 22,211
  • 4
  • 65
  • 88
  • It's worth noting that when Dart moves to a non-nullable by default type system in the near future, it will be possible to have required named parameters by making the type for the parameter non-nullable. – Ben Konyi Jan 13 '20 at 02:18
  • @BenKonyi Not necessarily. It might just require a default value. – Abion47 Jan 13 '20 at 02:30
  • At that point it's still technically required, but a default has been provided so it would defeat the purpose of marking it required in the first place. However, I'm not sure how the analyzer would behave currently if you mark something as required and provide a default. – Ben Konyi Jan 13 '20 at 02:34
  • @BenKonyi By that logic all parameters are required as even the optional parameters are implicitly assigned a default value of `null`. An optional parameter with an explicit default value is still optional. An optional parameter of a non-nullable type may just require an explicit default value. At any rate, it's too early to tell how non-nullable types wil behave in optional parameters. Dart may just pull something out of its ass for a non-null implicit default value, particularly for built-in value types. – Abion47 Jan 13 '20 at 02:55
  • I'm working on porting some of the SDK code now, and it looks like the analyzer will actually complain if you have a non-nullable named parameter without a default value. For example: `error • The parameter 'details' can't have a value of 'null' because of its type, so it must either be a required parameter or have a default value. • sdk_nnbd/lib/vmservice/vmservice.dart:95:58 • missing_default_value_for_parameter` At that point the named parameter is effectively required. – Ben Konyi Jan 13 '20 at 18:49
  • @BenKonyi That error message reads less like a non-null named parameter is effectively a required named parameter and more like a non-null named parameter is expressly forbidden unless it is given an explicit default value. The "must be required" bit is impossible to rectify as Dart doesn't support required named parameters, so in order to satisfy the error message the parameter must be given a default value. So it sounds like my assumption before was correct. – Abion47 Jan 13 '20 at 18:55
  • That's not true given the [language specification](https://github.com/dart-lang/language/blob/master/accepted/future-releases/nnbd/feature-specification.md) for non-nullable by default. See the bit on the new built-in `required` identifier under the `Syntax` section. – Ben Konyi Jan 13 '20 at 19:00
  • @BenKonyi So they canonized the required annotation into an actual keyword. That certainly changes my understanding of the situation. Still, it's unclear when this feature is going to be released. A change of this magnitude may even warrant a Dart 3.0 release. – Abion47 Jan 13 '20 at 19:03
  • @BenKonyi Though that still doesn't really change the fact that a non-null named parameter is _not_ "effectively required", hence the necessity of the `required` canonization. (Late reply, been busy) – Abion47 Jan 16 '20 at 23:38