Allow using an import prefix with ".."

[matanlurey]

        reflector
          ..registerFactory(ExampleService, () => new ExampleService())
          ..registerFactory(ExampleService2, () => new ExampleService2());

Results in:

The name 'reflector' refers to an import prefix, so it must be followed by '.'. #prefix_identifier_not_followed_by_dot

I don't see a technical reason why this can't be allowed.

[lrhn]

The technical reason is that x..y evaluates to the same value as x and reflector, being a prefix, doesn't have a value.

If you can write reflector..something() then you can also write var x = reflector..something();, and since we can't allow you to write the latter, we won't allow you to write the former either.

We could allow it, adding constraints that say that e .. cascades is allowed with e being a prefix only when it occurs at a position where the value isn't used, but that extra complexity isn't really worth it. Calling multiple methods on a prefix in sequence isn't happening often enough to allow it.

So no, that particular case probably won't happen.

(We have a similar problem with static members, and I think we should fix that. If you write int..parse("42")..parse("37") (which was the static function I could remember), then you get an error because it's treating int as an expression that evaluates to a value, here a Type object, and the type object does not have a parse method. I have an idea to fix that, along with some other simplifications, but currently it also doesn't work as you'd perhaps expect. Ditto for super..something(), cascades really only work on objects).

[matanlurey]

I understand the technical reason it doesn't work, but I'd like this to be considered as a FR.

[lrhn]

I think it is possible to change the spec in a consistent way that won't cause an error if the result of this cascade is not used in a value-expecting context. It'll be a major rewrite of expression semantics, but as a smaller extension to a rewrite that I want to consider anyway for other reasons,
I worry that it will also allow other things that are more silly, like a sole prefix; as an expression statement (it's meaningless, so it's probably a mistake), but I guess we can handle that by keeping the requirement that a prefix must be followed by a . or .. or ?. or whatever other things we want to allow.

Not impossible, not something I'd personally do just by itself, it's not worth that amount of comlexity, but as part of another change it might be simpler.

[eernstg]

It would be possible to achieve a similar conciseness and convenience using a different mechanism: If we import certain name spaces in a given scope (similar to open in SML) then we could avoid the repeated reflector: registerFactory would simply be in scope just like everything else which is in scope at that point:

class C {
  import reflector; // Add exported namespace of library imported as `reflector`.
  static void setupFactories(MyEnum e) {
    registerFactory(ExampleService, () => new ExampleService());
    if (e == MyEnum.FOO) {
      registerFactory(ExampleService2, () => new ExampleService2());
    }
  }
}

class D {
  void doCishStuff () {
    import C; // Add static namespace of class C to this scope.
    import MyEnum; // Add enum values.
    setupFactories(FOO);
  }
}

This might be less disruptive with respect to the semantics of expressions, but it would of course be necessary to handle name clashes in a reasonable manner.