[swift-evolution] Revisiting SE-0110

[Víctor Pimentel Rodríguez]

On Mon, Jun 5, 2017 at 9:31 AM, Gwendal Roué via swift-evolution <
swift-evolution at swift.org> wrote:

> The motivation section is not at all about any "type checker problem".
> It's about a postulate that has been proven horribly source-breaking, and
> counter-productive. The type safety argument is moot. The principle of
> least surprise has been blown away by SE-0110, putting Swift aside from the
> majority of other languages.
>
> I'm surprised that everybody tries to workaround SE-0110 consequences,
> admitting that it's relevant, instead of revisiting SE-0110 at its very
> root.
>
> Gwendal
>

+1 to this.

In practice, we have seen that the previous behaviour was incredibly
versatile and it allowed for more expressive code; using tuples in generic
types is much more pleasant to use (eg: Dictionary and similar
collections). I suppose most users of that Dictionary API did not know that
those blocks were accepting tuples and not several parameters, but still
they were productive with those APIs. Now we will require them to know what
I consider is a implementation detail, which adds a small cognitive load
when they try to use them.

So, which syntax is considered to be better? To me, every proposed syntax
is worse than the previous one, even more considering that this will be a
breaking change. And we do not need to invent some examples, we have real
usages that we can reason about:

https://github.com/Alamofire/Alamofire/blob/c8700ac7ea6b7efa7200e2920bf528e88b4dbee6/Source/ParameterEncoding.swift#L245

        return components.map { "\($0)=\($1)" }.joined(separator: "&")

I suppose that with Swift 4 that line of code will be rewritten as this:

        return components.map { "\($0.0)=\($0.1)" }.joined(separator: "&")

No matter the workaround, that will be the case. That is not Swift code I
want to write nor maintain.

Can't we delay the release of SE-0110 until Swift 5, where we can reason
more about its consequences? Are the gains in compilation times so
impressive? Do we want to hinder such code patterns because of "type
safety"? Are there any real world examples where that has been an issue?

Thanks,

-- 
Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170605/21880722/attachment.html>