Xiaodi, I'm interested in your opinion, don't you think that *SE-0066* was the main
proposal that separated (Int,Int)->() and ((Int,Int))->() function *types*?
(https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md)
'Proposed solution' section of this proposal clearly separates function *type* of one
tuple argument and of a list of arguments, no?
It seems like this proposal was NOT fully implemented in Swift 3 or was implemented
with bugs, or full implementation was delayed, and it just should be fully
implemented in Swift 4, independent of SE-0110 proposal.
This is why I can't understand, how revisiting of SE-0110 *can help at all* ?
OK, let's say we revisited/rejected SE-0110, let's forgot about it for a moment.
What's next? How the problem with two *separated* types for func/closure should be
solved when one type is expected and other type is provided? Definitely we need new
formal proposal for this to discuss in details.
Again, even *without* SE-0110 type of (Int,Int)->() should be in Swift 4 not the same
as ((Int,Int))->(). This means that you can't "just sent" instance of one type if
other type is required.
Vladimir.
On 08.06.2017 6:34, Xiaodi Wu via swift-evolution wrote:
On Wed, Jun 7, 2017 at 10:12 PM, Stephen Celis <[email protected]
<mailto:[email protected]>> wrote:
> On Jun 7, 2017, at 10:33 PM, Xiaodi Wu via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
>
> However, what I don’t get is why you’d have a mismatch here. Your method
`first` accepts a closure, and surely the type it expects should be `((String,
Conversation)) -> Bool` instead, since that is the type that the `filter` method
expects in the body of your implementation?
I must continue to ask for more justification as to why it's _so_ valuable
to
consider "(Int,Int)->()" and "((Int,Int))->()" to be different in _most_
cases.
Even in the contrived-described example above, the function may be reusable
and
the engineer may pass "String" and "Conversation" objects directly in some
cases,
and this distinction only makes things more difficult and requires
cumbersome
workarounds.
I know you feel that the ship has sailed, and I understand the ambiguities
these
proposals intended to clarify, but for the most common cases, treating a
function
that takes a single tuple the same way we treat a function that takes the
same
number of values that same tuple contains is...really nice, so maybe
there's a
better way to disambiguate.
Again, an argument list was once a tuple: this solution was investigated and
"completely abandoned" early in the development of Swift "for a large number of
reasons (including inout, default arguments, variadic arguments, labels, etc)".
Removal of implicit tuple splatting was outlined in SE-0029. Namely, for a function
`foo(_:b:)` called using a tuple `x`:
>A call to foo(x) looks like a call to an overloaded version of foo, both to the
compiler and to the human who maintains the code. This is extremely confusing if you
don't know the feature exists.
>There are real ambiguities in the syntax, e.g. involving Any arguments and
situations where you want to pass a tuple value as a single parameter.
>The current implementation has a ton of implementation bugs - it doesn't work
reliably.
>The current implementation adds complexity to the type checker, slowing it down and
adding maintenance burden.
>The current implementation doesn't work the way we would want a tuple splat
operation to work.
...
>The root problem here is that we use exactly the same syntax for both forms of
function application. If the two forms were differentiated (an option considered in
“alternatives considered” below) then some of these problems would be defined away.
However,
>[A]ctually designing this feature would be a non-trivial effort...
>We don't have an obvious sigil to use. "prefix-star" should be left unused for now
in case we want to use it to refer to memory-related operations in the future.
>Making the tuple splat operation great requires more than just fixing the syntactic
ambiguities we have, it would require re-evaluating the semantics of the operation
(e.g. in light of parameter labels, varargs and other features).
The removal of tuple splatting was approved during Swift *2* Evolution; it so happens
that one particular segment of the feature was not excised until SE-0110, but the
writing was on the wall, so to speak, for 18 months.
I'll work with whatever final solution the Swift team comes up with, but in
the
meantime I'm not going to shy away from reacting to regressions.
I've referred to these regressions as "ergonomic" in the past, but it's more
about expressiveness. Swift 3 (and earlier) syntax allowed for functional,
point-free expression that could amount to very succinct, readable code.
The code
Swift 4 requires is harder to read and harder to maintain.
Stephen
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
