Compile-time error when loading a library with the same name

[peter-ahe-google]

Right now, the specification says:

"It is a compile-time error to import two different libraries with the same name."

I'm not sure this fully captures the situations we would like to diagnose.

I think it should be a compile-time error to import a library named L directly or indirectly from a library named L.

Also, it should be a warning if there are two libraries with the same name anywhere.

[peter-ahe-google]

Johnni mentions that we should be careful about preventing exporting from the same library.

---

cc @johnniwinther.

[peter-ahe-google]

I'm deleting the comment #­2. That arose from a stale assertion in a co19 test.

[gbracha]

Added Accepted label.

[gbracha]

Added this to the M1 milestone.

[munificent]

it should be a compile-time error to import a library named L directly or indirectly from a library named L.

Would that break circular imports?

[gbracha]

We certainly don't wnat that to happen. We'll look into this and see what if anything makes sense.

[gbracha]

Removed this from the M1 milestone.
Added this to the M2 milestone.
Removed Type-Defect label.
Added Type-Enhancement label.

[sigmundch]

I just noticed this part of the specification, and I was actually surprised when I saw it. I saw this error in my code this week as it just got implemented as part of the editor.

I understand that we want to follow some dot-naming conventions to avoid these errors (as mentioned in issue #3206), but I was hoping we could avoid having additional naming constraints than we actually need.

Consider the following scenario. I depend on 2 libraries created by other people, which have the same library name:

  project1/a.dart:
    library a;
    ...

  project2/a.dart:
    library a;
    ...

  c.dart:
    // Suppose I import both in my code ...
    import 'package:project1/a.dart';
    import 'package:project2/a.dart';
    ...

There is actually no dependency in my code on the library names (assuming I'm not using mirrors) and no duplicate definitions, but I'll get an error. Note that I can circumvent the error by creating a 'trampoline' library:

d.dart:
  library d;
  export 'package:project1/a.dart';

then change c.dart:
  import 'd.dart'; # same as project1/a.dart, but with a different library name
  import 'package:project2/a.dart';

The fact that I can work around the error makes me wonder whether the error should be there in the first place.

I'm sure I'm missing a lot of details about why we have this rule. May I ask, what is the actual motivation for the rule? Is it so that runtime mirrors can uniquely identify a library? If so, maybe we meed to avoid 2 duplicate libraries names in the entire isolate? I personally don't want such error either, and I'm not sure what the right solution is here. Some ideas/proposals:

* remove this error altogether?

• use a compile-time warning, instead of an error?
• convert this compile-time error into a runtime error, but only show the error when using APIs that depend on having unique library names. For instance, when using the mirror API to find a library?

With the partial information I have, I currently prefer the third option.

[gbracha]

Removed this from the M2 milestone.
Added this to the M3 milestone.

[gbracha]

Removed this from the M3 milestone.
Added this to the M4 milestone.

[gbracha]

We've eliminate the requirement that library names do not conflict in the draft 0.32 spec.

---

Added Done label.

[gbracha]

See issue #9053 and issue #9054.