Summary

The String.fromEnvironment and int.fromEnvironment const constructors will have a non-null defaultValue default value.

What is changing:

The String.fromEnvironment and int.fromEnvironment constructors both have a defaultValue optional parameter which has a default value of null.
This is changed to the empty string and the integer zero respectively.

Why is this changing?

These are factory constructors, and in Null Safe code, constructors cannot return null.
As such, having a default value of null will not work. We picked the most neutral value for the types as the new default value.

The bool.fromEnvironment constructor is unaffected because it already had false as default defaultValue.

Expected impact

Code which uses either constructor with no specified default value will get a different result if there is no declaration for the requested key.

If code checks for the presence of a key by checking whether String.fromEnvironment(key) evaluates to null, it will now fail.

Code like const int.fromEnvironment("port") ?? computedPort() will no longer work. It can't just use computerPort() as default value because the default value for a constant constructor invocation must be constant.

The impact can be large for code which uses the current feature, but it is not expected that the feature is used that much.

Checking whether a key is present can be done by something like:

  const bool keyPresent = String.fromEnvironment(key) != String.fromEnvironment(key, "_");

which is not as convenient.

Allowing a factory constructor to return null is not a viable choice in Null Safe code.
Changing the constructors to be something other than const constructors, but keep them being constant, would require adding such a feature because the language currently doesn't have any.