This addition would be nice for importing record macros, defrecord defines 3 different arities: 0, 1, and 2.
> On 26 Dec 2020, at 09:43, Devon Estes <devon.c.es...@gmail.com> wrote: > > > 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. >>> >>> -- >>> 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. >> >> -- >> 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. > -- > > _________________ > 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. -- 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/F12F687F-F146-4F1B-BA78-6594C6107BEF%40wojtekmach.pl.
