Fair enough, I know when to give up on a losing battle. 

Would you consider an alternative like Tuple.wrap/1. It would work exactly 
like List.wrap/1 but doesn't carry the baggage that "error" and "ok" would 
have. This way I could still accomplish the goal of keeping pipe chains 
clean with something like.

value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)

Which is a bit wordier but functionally equivalent to the original proposal.

On Tuesday, April 16, 2019 at 6:04:55 PM UTC-4, José Valim wrote:
>
> Hi Tom,
>
> You don't have to buy the arguments, we can agree to disagree, but they 
> are still the reason for not adding such functions to Elixir. :)
>
> I also agree with is_even and is_odd being similar convenience functions 
> but they do have a rationale. They were added before defguard existed. At 
> the time, writing guards was a bit more bureaucratic. But if is_odd/is_even 
> were proposed today, they would most likely have been rejected as well.
>
> Elixir already has a perfectly fine syntax via curly brackets for creating 
> ok and error tuples, that also works on matching, so my recommendation is 
> still to build an extra vocabulary in your app or as a separate library.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Tue, Apr 16, 2019 at 11:46 PM <t...@scalpel.com <javascript:>> wrote:
>
>> I disagree that this should be a library. (I've already done this in my 
>> app and would be fine extracting it into one though) I don't buy the 
>> slippery slope argument.  The functions are very simple to create and 
>> maintain, and it's not like the Tuple module is overflowing with 
>> complexity. We have things like 'is_even' and 'is_odd' because they are 
>> common to work with. :ok and :error are insanely common in elixir 
>> codebases. Why not add convenience methods?
>>
>> On Tuesday, April 16, 2019 at 5:22:38 PM UTC-4, José Valim wrote:
>>>
>>> Hi Tom, thanks for the proposal.
>>>
>>> As OvermindDL1 already hinted, this can lead to a slippery slope where 
>>> we need to add bang variants, question mark variants, ok/1/2/3/4 to deal 
>>> with arities and so on. I would suggest building this vocabulary as 
>>> necessary in your applications or, if you want to share it with the world, 
>>> it could be a nice library. Hint: the package ok_error seems to be 
>>> available. :)
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:12 PM OvermindDL1 <overm...@gmail.com> wrote:
>>>
>>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, t...@scalpel.com wrote:
>>>>>
>>>>> It is often the case that you want to wrap the result of an operation 
>>>>> in an ":ok" or ":error" Tuple. We should add convenience wrapper 
>>>>> functions 
>>>>> since this is so common and it cleans up otherwise ugly code.
>>>>>
>>>>> def ok(value), do: {:ok, value}
>>>>> def error(value), do: {:error, value}
>>>>>
>>>>
>>>> This could be quite useful!  On the other side it would be useful to 
>>>> add functions like these as well:
>>>>
>>>> def ok!({:ok, value}), do: value
>>>>
>>>> def ok?({:ok, _value}), do: true
>>>> def ok?(_), do: false
>>>>
>>>> And so forth for error as well.  They are not really useful on their 
>>>> own because matching is better, but for use in pipes that would be quite 
>>>> useful (right now I use the exceptional library, which does similar things 
>>>> and more).
>>>>
>>>> -- 
>>>> 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-l...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/elixir-lang-core/30614530-7e33-4cb8-bffb-63c18248d340%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/30614530-7e33-4cb8-bffb-63c18248d340%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 elixir-l...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/elixir-lang-core/0314757d-eff2-4b23-8130-a19ee921b254%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/elixir-lang-core/0314757d-eff2-4b23-8130-a19ee921b254%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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to