Edit: I did some searching after I posted this and realized just how common it was to have custom toString functions, so I take back what I said about not naming your own functions toString. Switching Basics.toString to Debug.toString could be a good solution, although that would be annoying for simple cases like converting an Int to a String (which is often needed in non-debug situations like setting up HTML/SVG attributes). Maybe there should be a specialized Int.toString function instead. I do think it's a sufficiently special case that 'always import qualified' is still the best strategy though.
On Friday, 19 August 2016 09:28:56 UTC+10, Ian Mackenzie wrote: > > It seems to me that the issues you are encountering come from two things: > > - Using a mix of qualified and unqualified imports > - Having a function the same name as one in Basics > > One solution is to never use qualified imports, but a better solution is > to *always *use qualified imports and just not name any of your own > functions toString (or min, or max, or degrees, or anything else in Basics > ). That way you never have any ambiguity between functions, you never > have to switch between qualified and unqualified (if, perhaps, you start > using Maybe.map in a file that already uses List.map), and it's always > clear where a function (or value) is coming from. > > On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote: >> >> import ModuleWithToString >> >> toString typeFromThatModule >> >> Compiles with unexpected results that you have to catch. >> >> import ModuleWithToString exposing (..) >> >> toString typeFromThatModule >> >> Doesn't compile: "use of toString is ambiguous: did you mean >> Basics.toString or ModuleWithToString.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.
