[swift-evolution] Three quick(ish) generics enhancements; *maybe* phase 1

[Chris Lattner]

> On Dec 23, 2016, at 3:13 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> My personal theory of the whole phase-one construct is that it's just a way to calm everyone down, so that there is more time to actually do some work on the code ;-)

Your theory isn’t exactly wrong: it turns out while the majority of people on swift-evolution want to talk about new features, that a large majority of Swift *users* don’t actually care about new features: they want the existing compiler to work better with its current feature set.

As such, the Swift team is focused on making the compiler crash less, compile faster, and add critical features necessary for ABI stability (a long term strategic goal).  This does lead to some new features that are demanded by the standard library (e.g. conditional conformances), but the majority of the focus is on reducing technical debt and improving the quality of the compiler.

> Afair, the conversation about this didn't fade out slowly, but was stopped by someone saying "that addition is to big to be considered now".
> I'm to lazy to fight with the medium to find a reference, but there is a draft for a proposal:
> https://github.com/SwiftInofficialEvolution/Home/wiki/compile-time%20parameters <https://github.com/SwiftInofficialEvolution/Home/wiki/compile-time%20parameters>
> 
> I think the idea is quite useful, but it might be confusing for some people that they can create Vector<Int, size: 4> but not Vector<Int, size: myIntValue>.
> The issue with the latter is obvious when you fully understand the concept, but if myIntValue is known to be a constant at compile time (or a fixed case of an enum…), it's harder to decide wether the compiler should accept it.

I would love to see this happen some day, but it is one of MANY things that I think need to happen over the next “10" years.  The concept of "Swift 4 stage 1” is to cause an intense focus on the most important issues, and this is one of many that can be added later.  As such, we should wait until we have the ability to properly consider additive features, and weigh them against each other to determine which is the most critical in the short term.  While there are a ton of really great things that can be added now, I am personally super focused on ensuring that new things build towards Swift being a great language in 20 years.

I’m happy to sacrifice cool new features in the short-term to ensure that Swift has a fantastic long-term future.

-Chris

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