I like `Enum.one/1`. Agree that it's confusing to have `take/1` return a single element and `take/2` returning a list, although Rails' `take` works like this.
If the collection is empty it returns nil naturally. A bang and non-bang version could work, this would make it work like Ecto's `one/2` function. <https://hexdocs.pm/ecto/Ecto.Repo.html#c:one/2> As for keeping things explicit, if we wanted to be explicit we'd still be writing for loops in C ;). I like abstractions and a rich set of functions in the standard library, where it makes sense and doesn't duplicate functionality. On Sunday, April 23, 2017 at 5:23:38 PM UTC+1, Matt Jadczak wrote: > > I don't think this is needed, but as far as naming suggestions go, perhaps > `Enum.one/1` would work, as it both indicates that a single element is > returned, and doesn't necessarily imply ordering like `first` would. > However, what happens when the Enum is empty? Do we need a bang and > non-bang version? As others have said, I think that keeping this explicit > is nicer. You can always add a private helper or a function to a > project-level utility module if you use this often. > > On Saturday, 22 April 2017 18:49:10 UTC+1, Myron Marston wrote: >> >> I don't think this would improve Elixir. Elixir favors explicitness over >> implicitness and fewer keystrokes and the only argument for this seems to >> be convenience. >> >> More worrying, `Enum.take/2` returns a list of items. If there was an >> `Enum.take/1`, I'd expect it to simply default the number of items taken, >> but to still return a list (even if it's just a list of one item). But >> from this thread it sounds like you're wanting an `Enum.take/1` that >> returns just the first item without it being wrapped in a list. IMO, that >> would be incredibly confusing. It would lead to different behavior for >> `&Enum.take/1` and `&Enum.take(&1, 1)` which would be very >> counter-intuitive. >> >> Myron >> >> On Saturday, April 22, 2017 at 7:10:27 AM UTC-7, Amos King wrote: >>> >>> You want to add a default of 1 to Enum.take/2? I personally don't mind >>> that but I think it takes away from the explicit nature of the module. I >>> prefer explicitness if we are only saving a few keystrokes. >>> >>> Amos King >>> Binary Noggin >>> >>> On Apr 22, 2017, at 04:12, Sam Davies <[email protected]> wrote: >>> >>> I understand the reasoning. That's why I suggest the name `take` NOT the >>> name `first` to make it clear there is no implied ordering. >>> >>> The use case for this is often while working in IEx. I have a collection >>> of _somethings_ and I want to see what one _something_looks like. I don't >>> care about ordering. >>> >>> Rails' ActiveRecord has a method called `take` which does much the same >>> thing - there is no implied ordering, it just grabs a member using some >>> unspecified ordering and returns it. >>> >>> We already have `take/1` which returns the "first" X elements, so it >>> seems logical to me to extend that to `take/0` which returns the "first" >>> ONE element. >>> >>> On Thursday, April 20, 2017 at 5:55:22 PM UTC+1, Allen Madsen wrote: >>>> >>>> Also hd, which takes the head of the list. >>>> >>>> Allen Madsen >>>> http://www.allenmadsen.com >>>> >>>> On Thu, Apr 20, 2017 at 12:44 PM, OvermindDL1 <[email protected]> >>>> wrote: >>>> >>>>> Two things: >>>>> 1. The `List` module already has a `List.first/1`. >>>>> 2. Not all enumerables have a concept of ordering, like a map, so I'm >>>>> not sure an Enum version of such a thing makes conceptual sense? >>>>> >>>>> On Thursday, April 20, 2017 at 10:33:11 AM UTC-6, Sam Davies wrote: >>>>>> >>>>>> When working with collections it's often convenient to grab the first >>>>>> element that comes to hand. I find myself writing this a lot: >>>>>> >>>>>> `Enum.take(collection, 1)` or `Enum.at(collection, 0)` >>>>>> >>>>>> How about a function `Enum.take/1` which takes only the collection >>>>>> and returns the "first" value (I avoid naming it `Enum.first/1` since >>>>>> some >>>>>> collections may not have any concept of ordering). >>>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/69a0953e-07b3-4cc6-8cc0-bee718337ea5%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/69a0953e-07b3-4cc6-8cc0-bee718337ea5%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/bd395d6b-e64d-41ef-970e-8ac33c0e279c%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/bd395d6b-e64d-41ef-970e-8ac33c0e279c%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/9123abef-0f2a-47a8-8e93-69626f9515b2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
