[swift-dev] Hello!/Obs. Language Elements/extent Swift for loops/Tuples init. APL in Swift

[Brent Royal-Gordon]

Welcome to the Swift project, Ted!

A couple of general points:

* swift-dev is primarily for discussing Swift implementation details, like progress on fixing compiler bugs, binary representations of language metadata, or optimizations that should be applied. Discussion of high-level language features should generally be on swift-evolution.

* It's usually better to post unrelated proposals to swift-evolution as separate threads. This allows everyone to keep the discussion organized and avoids mixing discussion of unrelated topics together.

On your specific suggestions...

> 1. On removing (possibly) superfluous language elements

Swift is pretty aggressive about removing things that are mistake-prone, rarely used, and easy to achieve in a different way. The C-style for loop and increment/decrement operators fit all three criteria.

> More important imho: do the best to maintain downward compatibility 
> e.g. save us from modifying 10000 source files written in 2016 in say 2021 when Swift 8.0 arrives..

We are trying to stabilize the language; the hope is that Swift 4 will be a less jarring transition than Swift 3, and Swift 5 less jarring than Swift 4, and so on. But accomplishing that means removing as much cruft as possible as *early* as we can.

> 2: Swift "for" statement: why not add this variants:
>  (to get rid of reverse, strides, generators..and other indirect stuff)
> 
> for i in 12 to 0 by -2 
> 
> for v:Double in x1 to -2.8 by -0.1   

Swift's philosophy is that, where practical, it's actually *better* to implement features in the standard library than to create special syntax in the language. Doing it that way sometimes means you need some extra function names or punctuation characters, but it also means that when you want to do something a little bit different—maybe you need to multiply the previous value instead of adding it, or you need to stride over NSDates instead of numbers—you can build things just like the features everyone already knows how to use.

In general, we try to design features that allow us to put *more* things in the standard library, not less. For instance, swift-evolution is currently reviewing a proposal called Property Behaviors which would allow us to make `lazy` and possibly `willSet` and `didSet` into standard library features, rather than special built-in language features, and thereby allow anyone to define similar special behavior attached to a property. Building striding support into the `for` loop runs opposite to that trend, and it's unlikely to find very much support.

> 3 . I beg you! Please, please, please implement implicit conversion between Floats/CGFloats/Double..
> Why does one need to convert floating point vars explicitly?

There are long-term plans to do something about this, but for technical reasons it's actually somewhat difficult. Basically, type inference gets slower when it has to consider more types. Allowing implicit conversions like these increases the number of types involved, which makes compiling slower. And I don't mean it adds a couple of seconds here and there; I mean it can make a compilation take minutes instead of seconds or hours instead of minutes.

This isn't impossible to overcome, and like I said, we do hope to do something about it eventually. But the time isn't right yet.

> I can't treat tuples as an array, which in this case would be handy to initialize all the tuple elements.

There is an active discussion on swift-evolution right now about treating tuples as fixed-size arrays, including subscripting and declaration shorthands. The current thread is called "CollectionType on uniform tuples [forked off Contiguous Variables]".

If you'd like to discuss any of these further, please start a thread on swift-evolution; that's the appropriate venue for this kind of discussion.

-- 
Brent Royal-Gordon
Architechies