[Breaking change request] String.fromEnvironment and int.fromEnvironment const constructors will have a non-null defaultValue default value.

[lrhn]

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.

[franklinyow]

cc @Hixie @matanlurey @dgrove @vsmenon for review and approval.

[Hixie]

This seems like an undesireable change. String.fromEnvironment in particular seems like it should be able to distinguish a present empty value from an absent one, and Flutter does rely on this feature in some of its code (e.g. devicelab/lib/framework/utils.dart).

Could these factory methods be defined as factory? String.fromEnvironment() or some such to indicate that they can return null?

[lrhn]

The reason to have factory methods in Dart is to be able to switch between generative constructors and factory constructors without breaking clients instantiating the class^*. As such, providing a feature (nullable return type) which only works on one of them is not desirable.
The two fromEnvironment constructors have been the only two cases needing it so far, so adding a general feature just for those two does not seem worth the effort.

That is, this change is not made to improve the API, but to make it possible at all in a Null Safe setting. It's not something we can choose not to change. Either we need to add more features to the language (with a questionable cost/value ratio) or change the constructors in some other way, but we can't return null from a constructor in Null Safe code with the current Null Safe design.

The other option we have found is to make defaultValue a required parameter. That would make the API harder to use in almost all cases, and it would not provide any extra value. You can still always provide a defaultValue and get exactly the same behavior. With a default value of empty string/0, you can also omit the defaultValue parameter and get something which is a reasonable default in many cases.

If you want to distinguish an absent value from the default value, you still can do so precisely as described above(even if it's cumbersome and not something you can abstract over), or you can use a slightly less precise check like:

const String flag = String.fromEnvironment("flag key", defaultValue: "<NOT PRESENT>");
if (flag == "<NOT PRESENT>") { ... assume it wasn't there ... }
const int level = int.fromEnvironment("level key", defaultValue: -999999);
if (level == -999999) { ... assume it wasn't there ... }

These tests can be foiled, but in practice that will only happen with malicious intent, and the only effect the user gets is to act as if no value was passed, which the code should be ready to handle anyway.

So, there are workarounds.

The code linked in the Flutter utils.dart file is already questionable. It's unclear how the code would react to an empty string value, but it is possible to pass one as -DlocalEngine=.

The code would just need to change the absent-check for .isEmpty instead of == null, and it would have the added advantage of not trying to pass an empty string as a command line argument.

I believe that in most cases, an empty value can be treated the same as an absent key without any actual loss of user power because an empty value is already a questionable input. (A boolean declaration should use =true, not an empty string).

About allowing nullable return values from factories: Adding return types to constructors in general is a personal wish of mine, but not something we can do in the scope of the NNBD change. That would, if it ever happens, likely be part of a major revamp of constructors in general. Not sure whether it would actually allow you to return null, or if it must still be a subtype of the class type (but async constructors have been requested, so there is that).

^*: It may still break classes extending the class, so the abstraction isn't pure. It would be better if we could define generative constructors which could not be used for super-class constructor invocations.

[Hixie]

The reason to have factory methods in Dart is to be able to switch between generative constructors and factory constructors without breaking clients instantiating the class

Ever since we got rid of new, that use case sort of went away. Nowadays I don't think there's really any strong motivation left for factory methods, they're just weird syntax for static methods as far as I can tell. (Except for redirecting constructors, but it's weird that those get labeled "factory" anyway, we could identify those just by the "=" syntax.)

These tests can be foiled, but in practice that will only happen with malicious intent

That seems like a pretty terrible place to be in terms of API design. We shouldn't need to hope there's no malicious intent for our APIs to work. (What if the environment variable comes from the network, e.g. HTTP_xxx in a CGI context? Then it really could be malicious.)

It's unclear how the code would react to an empty string value, but it is possible to pass one as -DlocalEngine=

Why is it unclear? It seems pretty clear that that should be treated as an explicit local engine whose value is the empty string. Sure, it's unlikely to be useful, but there's plenty of strings that are unlikely to be useful.

To be honest, it seems a bit weird that we're saying factory methods can't return null any more. I guess in general we want people to switch to real static methods if they have that use case, and the only reason that doesn't work here is that we want to encourage people to use const with these constructors?

In any case, these constructors are already highly magical (they're const factory constructors with external bodies, which is not a thing a normal Dart program can express!). I recommend we just make them more magical for now, allowing them to continue to return null, until the day we return to environment variables in Dart in general to address them more rationally.

[matanlurey]

LGTM in terms of changing this particular API (and making factory methods return non-null).

[lrhn]

One option we have for making migration easier is to add a bool.hasEnvironment(String key) constructor too. Then you can write bool.hasEnvironment("key") ? String.fromEnvironment("key") : null if you want to keep a null for the non-existing case.

[vsmenon]

lgtm assuming we can land this without breaking.

The fromEnvironment constructors are somewhat magical, so I think it'd be reasonable to special case those as well if needed. (I.e., to make factories non-nullable in general.)

The reason to have factory methods in Dart is to be able to switch between generative constructors and factory constructors without breaking clients instantiating the class

Is this actually true for const constructors?

[lrhn]

Is this actually true for const constructors?

Yes. A class can have a const generative constructor, then change it to a const factory constructor which forwards to a subclass const constructor. As long as noone uses it as a superclass constructor, that still works. And if someone uses it as a superclass constructor, you're stuck with it, which is a hole in the entire theory.

(I prefer to only expose factory constructors where possible, to prevent people from extending classes not intended for extending).