[swift-evolution] Normalizing operator's types
Jeremy Pereira
jeremy.j.pereira at googlemail.com
Thu Jun 16 08:57:42 CDT 2016
> On 15 Jun 2016, at 21:07, J. Charles N. MBIADA via swift-evolution <swift-evolution at swift.org> wrote:
>
> Hi Swift,
>
> Since the "removal" of curried function, I am looking for some elegant ways to work with partial functions (and reduce creation of closure and nested func for the developper).
>
> And now I am asking myself if it's not better to align operator's types to the arrow style instead of using tuple argument style.
>
> For example:
> Why Int.multiplyWithOverflow's type is (Int, Int) -> (Int, overflow: Bool) instead of (Int -> Int) -> (Int, overflow: Bool)
That looks wrong to me. That says that Int.multiplyWithOverflow is a function that takes another function (of type (Int) -> Int) and returns a tuple.
What you really want is a function that takes an Int and returns another function that takes an Int and returns the tuple i.e. its signature would look like this
(Int) -> ((Int) -> (Int, Bool))
If we assume -> is right associative we can simplify to
(Int) -> (Int) -> (Int, Bool)
which makes more sense but is less clear to most programmers than the current syntax.
>
> When curried function will come back (if it come back, which is a personal hope) that will avoid many refactoring.
>
> I think that, write this : let f:(Int, Int) throws -> Int = (+) seem a bit ugly for this purpose
> let f:(Int -> Int) -> Int = (+) seem more suitable.
>
> We could imagine that in the future the compile could automatically create a closure if the programmer define something like
>
> let lmul: (Int) -> (Int) -> (Int) = (*)
>
> and then, doing the habitual stuffs : let mulOfTwo = lmul(2)
>
>
> Kind regards,
> --
> jcnm
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list