My humble proposal: removing the possibility to expose everything, expecially for import statements.
The main upside is that it gets really simple to “resolve” a name, even without LSP, and this removes one source of implicitness.
The main downside I see is for hello world/first learning steps cases, which… may be a reasonable use case actually?
Is there any scenario outside of import expressions? Because I’m not familiar with, if there is one I would like to learn that.
module Foo exposing (…)
elm-review supports 2 rules that go in the direction of the proposal: NoExposingEverything and NoImportingEverything.
In general I’m in favor of this. It’s what I feel like most consider a best practice anyway.
For imports, it would also remove one implicit way of introducing shadowing, and then we could remove the forbid the implicit one (import A exposing (shadowed)).
As mentioned, I feel like this feature can make it easier for newcomers to get started with Elm. But this might actually not be true, because not understanding where something comes from is confusing when debugging, but being able to pull out a function from an import that exposes everything can be confusing when writing as well.
If this gets removed, the syntax to import/expose constructors (import A exposing (Type(..))) may be a bit lonely, but that’s not necessarily a problem. Though you’d still have this somewhat implicit import for the constructors so I think it would make sense to change this as well.
I feel like the biggest complaint about this would be for the case (which I feel is somewhat common) of exposing Html functions. In practice, using qualified imports there feels quite nice in my opinion.
For exposing everything, the common use-case are for quick experimentation and for exposing tests. I think it would be fine to remove anyway, but that’s me and and my code style speaking.
I use elm-analyse's Import All and Expose All checks to mitigate this pattern. Since we’re using the tool before commiting our changes, this pattern rarely show up in the production code.
If (..) were removed I would not be upset.
Occasionally, it is useful when doing some rapid prototyping. And since we have elm-review rules to tidy it up automatically, I guess the rapid prototyping use case is good enough reason to keep it in.
I think this could be resolved by including (..) as a Debug syntax and disallowing it on optimized builds. Then you get both the ease of quick prototyping with (..) and you keep everything explicit when it ships to production.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.