I would love a compiler warning for this. It already warns about unused imports. Warning about naming collisions would be in the same spirit of encouraging code quality.
Even with the warning, this is a good reason to use unqualified imports sparingly. If the package name is long or I use it frequently, I might shorten the name (for example "import Data.Integer as Int"). But I almost never import functions without a namespace. The Elm documentation warns that unqualified imports are a bad idea, but this warning is hidden in the API Design Guidelines <http://package.elm-lang.org/help/design-guidelines> > A function called State.runState is redundant and silly. More > importantly, it encourages people to use import State exposing (..) which > does not scale well. In files with many so-called "unqualified" > dependencies, it is essentially impossible to figure out where functions > are coming from. This can make large code bases impossible to understand, > especially if custom infix operators are used as well. Repeating the module > name actively encourages this kind of unreadable code. > With a name like State.run the user is encouraged to disambiguate functions > with namespacing, leading to a codebase that will be clearer to people > reading the project for the first time. > On Wed, Jul 20, 2016 at 8:54 AM, Peter Damoc <[email protected]> wrote: > Will, > > did you import elm-integer's toString and it did not give you an error > about the duplication? > > This sounds unexpected. Do you have a SSCCE showing this kind of problem? > > > > > > On Wed, Jul 20, 2016 at 5:12 PM, Will White <[email protected]> > wrote: > >> Just to be clear, in 1. I did `toString Integer`, expecting that to call >> elm-integer's toString, not Basic.toString. >> In the first bullet point, I meant to say "...even though `toString >> Integer` is valid...". >> >> >> On Wednesday, July 20, 2016 at 3:04:23 PM UTC+1, Will White wrote: >>> >>> Coming from https://github.com/elm-lang/error-message-catalog/issues/135, >>> I'd like to know what you think we could do about ambiguous uses of e.g. >>> `toString`. For instance: >>> >>> >>> 1. I was using elm-integer, which has its own `toString` function >>> for its massive integers, and I called it on an elm-integer Integer. >>> 2. My code *actually* called `Basics.toString` on the Integer, so >>> the result was not as expected. Luckily I caught it. >>> >>> I can think of two ways to handle there being more than one toString >>> around: >>> >>> >>> - Warn the developer that the use of `toString` is ambiguous, even >>> though `Basics.toString Integer` *is* valid (Basics.toString changes >>> *any* type to a String). Namespacing the toString would make the >>> warning go away. >>> - Call the toString that's in the same module as the type of the >>> argument is in, i.e. the toString that's in the same module as Integer. >>> >>> I'm sure this will affect other functions as well as `toString`. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Elm Discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > > -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
