> On Jun 12, 2017, at 5:12 PM, Ted Kremenek via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> - Sometimes (often?) refinements aren’t part of a grand design. They evolve
> in the mind space from usage of Swift. In other words, greedy optimization
> is sometimes just a natural way discussion and design happens. The question
> in my mind is when these concerns come up should we throttle individual
> proposals and take more time to take a broader view? Maybe that’s the
> answer. Having been in discussions in the Core Team meetings I can say that
> sometimes it is clear there is a broader topic to be discussed, and other
> times it isn’t.
I would like to see an explicit place (maybe another list or a section of the
eventual discourse) where we can ideate. Ideation requires a less critical
environment than this list has been able to provide, and I think it has been
contributing a great deal to our inability to deal with the larger picture.
The exception to this are the manifestos provided by the core team, which I
would guess are a result of off-list ideation sessions, followed by
concentrated refinement.
In the absence of an official place, it seems that there are a lot of ad-hoc
places where this is being done in a fragmented way. The issue with this is
that, when I see “We had a long discussion on Slack”, I don’t know where this
Slack channel is, how to get an invite (or even if I am eligible for an
invite). Even if I have access to all of the places this discussion is
happening, it is so fractured that going back to find important bits of a part
of a conversation later is nearly impossible.
I would also like to see a place where ideas and known issues can be organized
and referenced.
A structure that has worked well in member-driven organizations I have been a
part of in the past is that of working groups. That is, we would larger
identify areas of interest for the future development of swift (e.g. Strings),
and then spawn a separate list or discourse section for deeper discussion
(anyone who is interested could join). The group’s mandate would be to work
through the big picture surrounding that issue (including an ideation stage)
and develop a resulting manifesto. That manifesto should be an evolving
document with known issues that need to be solved, and a record of attempted
solutions which failed and the reason for their failure.
I think this structure would take some pressure off of the core team and allow
deep thinking on important topics. It would free the main list to focus on
specific proposals based on the guideposts provided by the manifestos.
Discussions like the Great Access Modifier War would have been contained to a
working group, with the main list only receiving a recommendation at the end.
>> 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.)
>
> I agree. Do you have specific thoughts here on what could be done
> differently?
I think we can partially solve this by having an extra stage of “stability” in
our documentation. Right now, things are either officially part of the
language or they aren’t (with a very short beta period between WWDC and the
Fall). What I would like to see in the documentation is a notion of how sure
we are of a particular piece of API or syntax.
Unstable - This is actively under development/design and should be expected to
change. It is not safe to build frameworks on top of this.
Pre-Stable - We think we have a design which works, but we need to see how it
works in the larger ecosystem before guaranteeing stability. Anything built on
this should be prepared for potentially large changes in the future, and be
marked “Pre-Stable” themselves.
Stable - This has been extensively tested in the actual swift ecosystem and
proven itself a useful addition. Any changes to this in the future are
guaranteed to either be source-compatible or have a full depreciation cycle. It
is completely safe to build on.
I think being explicit about what we expect to change in the future, and having
a notion of “stable” that is truly stable will give us a lot more freedom to
experiment as well as room to fix our mistakes.
Thanks,
Jon
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
