[swift-evolution] Dynamic Class/Struct Definition At Run Time

[Xiaodi Wu]

On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution <
swift-evolution at swift.org> wrote:

> Hi David,
>
> Thanks for your reply., OK, I think I understand.
>
> It then is a capacity problem, right?
>
> In effect, it means restricting people from bringing perhaps very valuable
> (not necessarily my contributions)
> and essential ideas forward, which could play a crucial role improving
> Swift.
>
> I think this is a very negative aspect. surely bouncing creative people
> away,
> dropping their efforts and interest here altogether.
>
> The question then remains, where / when / how can one bring topics
> that are taking a longer stretch and are not bound to a certain release of
> Swift,
> seemingly “outside” of this restriction under attention?
>
> if swift evolution is (currently? ) not open for new ideas/topics:
> I thought that was the primary purpose of Swift evolution?
>
> Kind Regards
> Ted
>

[Edit: David just wrote a very nice reply, but since I'm mostly done with
this email, I'll send it along anyway as a companion response.]

I think this is worth a reply, if only because I think we've touched on the
underlying issues somewhat obliquely in the past.

It's enormously interesting to talk about important questions of language
design here on the list: that's why we're here. And it's been magical to
see that an idea written here, pitched convincingly, comes into being in
the next version of a programming language.

Except it's not magic. Dozens if not hundreds of people spend time thinking
about and debating concrete implementation details, then a group of people
painstakingly implements the result. During the Swift 3 time frame, the
illusion of magic fell apart because even some excellently pitched ideas,
carefully thought out, never became reality. This results in a huge loss of
time and effort. Everything that didn't make it into Swift 3 needs to be
re-evaluated to some extent because features are not designed in a vacuum
and must fit in with the rest of the language. The best solution for a
problem that we could design after the Swift 2 release would look very
different from the best solution that we can design now.

The point is, since nothing is really magic, we have to make a concession
to the reality that ideas too far from identified priorities are much less
likely to become part of the next release. It may be fun and creative to
think about how, hypothetically, one would design dynamic facilities to
support Swift 3, but the truth is that there will never be a release based
on Swift 3 that additionally has dynamic facilities. It is simply not a
productive use of anyone's creativity, time, or effort to imagine how that
might look; we're better off channeling everyone's energy towards making
the real, actual upcoming release of Swift even better.

On 12 Oct 2016, at 21:48, David Hart <david at hartbit.com> wrote:
>
> Hello Ted,
>
> Please try to understand. As Xiaodi and others have said a few times, it
> has nothing to do with the topic being important or interesting. The
> current phase of Swift 4’s development does not allow any extensive
> discussion or review on topics which do not impact ABI stability:
>
> *Stage 1 focuses on the essentials required for source and ABI stability.
> Features that don't fundamentally change the ABI of existing language
> features or imply an ABI-breaking change to the standard library will not
> be considered in this stage.*
>
> On 12 Oct 2016, at 19:14, Ted F.A. van Gaalen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Apart from my perhaps fierce reaction, I am not aware of doing something
> wrong.
> and I still find this topic very important.
>
>
> David.
>
>
>
> _______________________________________________
> 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/20161012/708d144d/attachment.html>