[swift-evolution] [Draft] Tuple-Based Compound Optional Binding

[Patrick Smith]

I’m not really interested in a really rich language, just the most simple thing possible that lets me create rich apps. I like Vladimir’s description of there being more when you need it.

(I guess what I am concerned about is complexity as a writer. I want everything to be as consistent and logical as possible. I don’t really want any situations as a writer where I’m like ‘now hang on, this follows these particular rules’, or ‘this is this particular edge case’. I guess I’m a little worried about the piecemeal nature of the evolution process. Sometimes I think the way Apple works is so great since that they ‘marinate’ things for so long (e.g. Siri capabilities), they allow it internally to be discussed and prototyped and be released when it’s ready and not sooner.)

Patrick

> On 16 Jun 2016, at 1:42 AM, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> On Jun 15, 2016, at 5:04 PM, Austin Zheng <austinzheng at gmail.com <mailto:austinzheng at gmail.com>> wrote:
> 
>> 
>>> On Jun 14, 2016, at 7:12 AM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>> On Jun 14, 2016, at 11:31 AM, Patrick Smith via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> Thanks Xiaodi. Interesting arguments there. It possibly seems a shame to me, because it has knock on effects of making other things more complicated. But I do see how for the most simple case of unwrapping a single Optional, it makes sense.
>>>> 
>>>> As much as I would like Brent’s proposal to make things easier to type, I think nesting things inside a tuple, where a reader must keep track of which input matches which output, could lead to harder to follow code.
>>> 
>>> Isomehow I think last yesterday's keynote should recast some expectations about the degree of complexity (richness) the language will ever reach... Somehow xamarin/c# might endupmbeing swift++ for many people
>> 
>> How so? What proposals might the core team accept that would confirm your suspicions; would this be one of them? Maybe I should drop Swift and move to C#, if that language is going to end up so much better than Swift in the future. It's never good to be tied down to a single language.
> 
> I think it is non-disputable that objc is a very simple language when compared to more recent languages. Today swift is capable of doing a lot of things, while still being a simpler language than older ones. Si the question for some people might be how much richer will swift become? Will it rival scala's type system? Will it rival java/scala/kotlin/ceylon/c++ for the ability to organize large codebases? Will it have the runtime/compile time code fluidity of D? Etc.. The only way to find out is ... there is none. So then who is swift for? Apple wants it usable by people off the street... not people with a degree in computer science, but the people who may one day get a degree or not. So i wonder this plus the fact that objc was enough for so many years doesn't  simply mean that there is already a cap on the sophistication swift will ever get!!! that they will touch everything around it, before they push it. Today i have a degree of expressiveness with c# that i cannot have with swift, is the gap going to increase of decrease? That is what i care to know about before I advise large corps to invest in swift or not. bored/curious devs (i included) will always easily pick it up, but should i advise a CTO to invest on it... 

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