Are we sure we want the library choose?

[BillDStrong]

This is a question of behavior. Don't we currently use the build tools to pull in the correct libraries? Or, am I misunderstanding the wording or context in your usage.

Is this proposal adding language that would be better defined in the implementation behavior?

Instead of explicitly telling the tools what to do in each case, can't we describe behaviors that accomplish the same tasks?

In this case, instead of adding all of this verbosity, can we add a convention for naming libraries

work.s.dart work.w.dart work.*.dart

to deal with these cases? I realize a lot of thought went into this, so I am curios if you thought along this approach. By naming the files with the same starting name and this hint, a very dartian thing to do, and importing specific libraries, the vm and packaging should have enough info to handle a large number of use cases.

Or we could add an environment specifier such as

env server;

or

env browser;

to serve the same purpose, if we need to be more explicit.

[nex3]

I'm not sure I understand your concrete proposal here. Are you saying that the tools would automatically look for a magic .s.dart suffix? That seems way too implicit and non-obvious; it would be entirely unclear to anyone reading the code that the import it contains could be resolved differently on different platforms.

[BillDStrong]

.s would be implicit, true. Adding .server would be more descriptive, I guess. There is nothing inherently wrong with using such a structure, and it is used throughout the web developer ecosystem, so is familiar to many of Dart's target audience.

And, this does follow Dart's pattern of doing the work to make the platform nice. This is why I suggested adding the "env" for human readability, and it can be used as we already do type checking.

However, I don't know if this fits every scenario envisioned with this proposal, which is why I've asked these questions.

For one, this took a lot more time to think up and write than I have had time to think about.

[nex3]

The problematic implicitness isn't the shortness of the name, it's the fact that the import is auto-detected from the filename in the first place. It should be possible to see from the library doing the import that the import is cross-platform and which files it might load.

[BillDStrong]

So, lets break this part into two sections. Naming the file .server.dart as a convention has no inherent evils, is what you are saying.

Not implicitly importing both files is what you object to?

We could then implicitly import both libraries by name, and let the name of the file dictate its environment?

[nex3]

I'm also not a fan of having the filename influence its semantics. And at the point at which you're specifying multiple files to import in your library anyway, what benefit does this scheme provide over the existing proposal?

[BillDStrong]

Your correct, it does lose much of its simplicity from the user perspective. Maybe I need to wait a day after reading a proposal to comment?

[zoechi]

I basically like convention over configuration so I'm basically in favor of such an approach. It could become messy though when one file supports 3 of x possible platforms. Creating an entry point library for each platform would be cumbersome. See my approach at https://github.com/lrhn/dep-configured-imports/issues/3#issuecomment-77514270