[swift-evolution] Swift phases and mis-timed proposals

[Austin Zheng]

Oh, no need to apologize! I didn't want to distract from the main point of
your post, which I think is very good. The fact is that SE-0110 introduced
unforeseen consequences, and that we need to deal with them one way or
another (including by reverting, if it comes to that).

The problem in this case is staging a refactor across two major versions of
Swift, in which the user experience is regressed by the first half of the
"necessary" work before it can be fixed by the second half. Throw in source
compatibility as a goal and you have a problematic situation.

That said, I've clarified what I wanted to, so I'll withdraw respectfully
from this conversation and allow others to express their views.

Austin



On Mon, Jun 12, 2017 at 1:48 PM, Paul Cantrell <cantrell at pobox.com> wrote:

>
> On Jun 12, 2017, at 3:03 PM, Austin Zheng <austinzheng at gmail.com> wrote:
>
> > The Great Access Modifiers Wars and the recent fussing of SE-110
> fallout are good examples of these problems.
>
> I want to mention that SE-0110 is part of a suite of proposals originally
> asked for or proposed directly by the core team as part of an overarching
> attempt to fix issues with how the type system handles function and tuple
> types. It was never intended as self-contained fussing over aesthetic
> purity, or pretty much anything else it's been accused as in recent posts
> to the list. In this case, there is a "coherent big picture"; the problem
> is that this big picture was laid out months ago and it's not really fair
> to ask newcomers to the discussion to dig through mailing list archives to
> try and find the relevant posts.
>
>
> Right, sorry to pick on 110. I realize that proposal has taken a lot of
> abuse and become a bit of a boogeyman.
>
> I do realize that there was a coherent (and good!) plan behind the
> sequence of SEs that lead to 110. And for the record, I DO NOT accuse
> anyone of “self-contained fussing over aesthetic purity!” More generally,
> I do not approve of the peanut gallery’s occasional degeneration into
> nasty ad hominems. I have the utmost trust in the expertise and motivation of
> the core team and proposal authors, who have done heroic, excellent work.
>
> The problem here as I see it is that that chain of tuple-related SEs that
> lead to 110, once approved, had unintended consequences for
> dictionary-as-collection operations and RxSwift — consequences that were
> hard to foresee in discussion, but that prototyping could likely have
> revealed earlier. (My concern #2.)
>
> We are now faced with the unpleasant prospect of working out those
> consequences under a tight timeline, and thus looking for a local solution
> within tight design constraints. (My concern #1.) It seems likely to me
> that we’re going to end up with yet another little language wrinkle that
> solves the immediate problem, but adds to language bloat.
>
> That’s probably the best we can do for the concerns raised by 110 for now;
> I do not mean to derail or denegrate that debate. My argument is that there
> may be an underlying process problem — and thus process solution — to
> consider for future work.
>
> Cheers, P
>
>
>
> Regards,
> Austin
>
> On Mon, Jun 12, 2017 at 12:47 PM, Paul Cantrell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> > On Jun 12, 2017, at 1:29 AM, Ted Kremenek via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >
>> >> On Jun 11, 2017, at 4:47 PM, Erica Sadun via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>
>> >> I think having a queue to submit "proposals for eventually", written
>> when the inspiration is there, and having a core team review (say once a
>> month or even once a quarter) of their viability for future Swift
>> directions would be amazingly valuable.
>> >
>> > This is a good point.  I think the concern about a queue is that ideas
>> in it may still be subject to starvation if the queue gets too long.  Ideas
>> also can atrophy in their relevance as the language evolves but proposals
>> stay in the queue.  It then becomes a delicate matter when closing out old
>> proposals. …
>> >
>> > The point about understanding “viable for future Swift directions” is
>> key here.  Viability really comes down to trajectory for the language.
>> None of us are fully omniscient about what is coming in future releases,
>> but we do have a sense of some of the priorities for the language that we
>> need to tackle, balanced with what **kind** of changes are still acceptable
>> to take into the language depending on the kind of disruption they cause
>> for users, the tools we have to mitigate any pain with those changes, etc.
>>
>> This touches on two related concerns I’ve long had about how
>> swift-evolution has worked so far.
>>
>> Concern #1 is that we consider proposals in relative isolation, on their
>> own merits. That’s understandable and wise. Without this focus, we’d never
>> reach conclusions about anything. However, this does tilt the process
>> toward greedy optimization as we traverse the language space. I worry that
>> there’s not enough attention to the big picture.
>>
>> Concern #2 is that it’s hard to know what to do with a proposal when the
>> ideal answer is “we need to see how it plays out in practice and then
>> decide whether to accept it.” Theoretical discussion untempered by
>> practical prototyping is a great way for a group to talk itself into a bad
>> idea. (This will especially be a problem with future work to build out
>> generics & existentials.)
>>
>> Swift is already a very featureful language, and not always in a good
>> way. A new feature that makes good sense in the context of a particular
>> problem may make less sense when we consider the totality of its effect on
>> the programmer model: its mental burden, its unforeseen interactions, its
>> surprising pitfalls. How often do we reviewers give only a perfunctory
>> answer to “Does this proposal fit well with the feel and direction of
>> Swift?” How often _can_ we give anything but?
>>
>> The net result is that IMO we tend to over-favor narrow solutions that
>> solve very specific problems, and under-favor simpler, more general
>> features that are good-enough solutions to _many_ problems at once — not as
>> nice for any _one_ of those problems in isolation, but nicer to work with
>> taken as a whole.
>>
>> The Great Access Modifiers Wars and the recent fussing of SE-110 fallout
>> are good examples of these problems.
>>
>> The work on ABI stability is perhaps a good model for non-greedy planning
>> guided by a coherent big picture.
>>
>> Do these musings make sense? I don’t have any clear answers, but hope the
>> observations are helpful.
>>
>> Cheers,
>>
>> Paul
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170612/9c74cd0b/attachment.html>