Hi Xiaodi, thanks for you reply, yes, I am aware from most things you write here, and also that what I wrote about dynamic facilities is probably not unique, as there are so many people involved and interested etc.
then you wrote > … Swift 3, but the truth is that there will never be a release based on Swift > 3 that additionally has dynamic facilities. You wanna make a bet? I see that as a challenge to work this out in detail much further, because I am convinced that these dynamic features in one form or another can be implemented successfully and add great value to Swift ! I come back with it much later when there is time, capacity and interest. Oh, btw I still do believe in magic. Since 1950. TedvG > On 12 Oct 2016, at 23:45, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution > <email@example.com <mailto:firstname.lastname@example.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 <da...@hartbit.com >> <mailto:da...@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 >>> <email@example.com <mailto:firstname.lastname@example.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 > email@example.com <mailto:firstname.lastname@example.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list email@example.com https://lists.swift.org/mailman/listinfo/swift-evolution