This seems like a source of potentially confusing issues to me, as mentioned earlier. I do admit that this would be a very rare occurrence, but in general it seems to go against what I see as one of the common patterns in Elixir, which is that things are often explicit rather than implicit. This explicitness does come at the cost of more typing when writing the code, but it also comes with the benefit of stability and clarity when reading or changing code, which I (personally) see as an overall benefit.
That said, if this does get implemented, using the :* atom for the arity would be explicit and would also keep the list passed to import/2 a keyword list. Bare atoms would be fine, too, but I see some value in the consistency of a keyword list for that argument as it removes the need for specific ordering. José Valim <jose.va...@dashbit.co> schrieb am Sa. 26. Dez. 2020 um 09:30: > I believe this was proposed a long time ago but I rejected it because of > name conflicts. For example, imagine you import all of "foo" and on v1 it > means adding both foo/2 and foo/3. However, on v2 the module also defines a > foo/1. There is a chance this new arity will conflict with a local foo/1. > > On the other hand, I would say having a function with the same name and > different arity as an import is something that should be avoided in general > (either by using a different name or not importing it), so I think it is > worth this addition. The only complexity I foresee in implementing this is > skipping the warning if one of the arities is invoked - but that's an > implementation detail. > > Therefore, I propose we do support this feature. My suggestion is to > represent said names with naked atoms, such as: > > import Enum, only: [:at, :map] > > Specific arities go at the end as any keyword list: > > import Enum, only: [:at, map: 2] > > Thoughts? > > On Fri, Dec 25, 2020 at 11:52 PM thojan...@gmail.com < > thojansse...@gmail.com> wrote: > >> > e.g if you have a function with the same name but one less argument >> >> That can actually also be considered as a function with default values >> (and in the end, default values generate such functions with different >> arities). If not then I think it's a code smell and the function needs to >> be renamed. >> >> On Friday, December 25, 2020 at 11:43:03 PM UTC+1 zachary....@gmail.com >> wrote: >> >>> Sorry, meant to say “in being able to say only import this *function*”, >>> not story :) >>> >>> On Fri, Dec 25, 2020 at 5:42 PM Zach Daniel <zachary....@gmail.com> >>> wrote: >>> >>>> There are theoretical name conflicts from not being able to say “only >>>> import this story” (e.g if you have a function with the same name but one >>>> less argument) what about import Mod, only: [func: 1..3]? >>>> >>>> On Fri, Dec 25, 2020 at 5:36 PM thojan...@gmail.com < >>>> thojan...@gmail.com> wrote: >>>> >>>>> Say function `foo` has multiple default values (two required args, two >>>>> with defaults). When importing, we must specify each arity that is used in >>>>> the calling code, e.g. >>>>> >>>>> ``` >>>>> import Foo, only: [foo: 2, foo: 3, foo: 4] >>>>> >>>>> foo(1, 2) >>>>> foo(1, 2, 3) >>>>> foo(1, 2, 3, 4) >>>>> ``` >>>>> >>>>> I expected that I could only import `foo/4`, and be able to call `foo` >>>>> with only two arguments and three arguments. Why? Because there is no use >>>>> case to force an imported function to be used only with a specific arity. >>>>> That would even be a code smell. >>>>> >>>>> Could we "generate" [foo: 2, foo: 3]` in addition to `[foo: 4]` to >>>>> support the call using its default values? >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "elixir-lang-core" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to elixir-lang-co...@googlegroups.com. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/28497895-3278-4de0-8423-99f9b9230597n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/28497895-3278-4de0-8423-99f9b9230597n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/38192124-1f41-407c-966e-82f223db3719n%40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/38192124-1f41-407c-966e-82f223db3719n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JEwAOA2WYnbGAjgNtP3-d8kukc8_ieejX4mprAfBSHsg%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JEwAOA2WYnbGAjgNtP3-d8kukc8_ieejX4mprAfBSHsg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- _________________ Devon Estes +49 176 2356 4717 www.devonestes.com -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGowJciKZ25GejXy2gaZ8TipXaECJa8hW9JiZNgOOL1zX1e51w%40mail.gmail.com.
