Are we sure we want the library choose? about dep-configured-imports HOT 7 OPEN

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.

from dep-configured-imports.

.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.

from dep-configured-imports.

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.

from dep-configured-imports.

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?

from dep-configured-imports.

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?

from dep-configured-imports.

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?

from dep-configured-imports.

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 #3 (comment)

from dep-configured-imports.