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 
> <swift-evolution@swift.org <mailto:swift-evolution@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 <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 
>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to