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

[Ted F.A. van Gaalen]

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.wu at gmail.com> wrote:
> 
> On Wed, Oct 12, 2016 at 3:37 PM, Ted F.A. van Gaalen via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161013/b3c98a01/attachment.html>