[swift-evolution] Proposal: Add "none" and simplify the language.

[品雪]

To have ? in the symbol is much better than looking back again and again to
ensure variable is initialized or not for me.

Ruby style of fields naming is even better for reading, though a little
burden for writing.

On Sat, Jan 9, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> > var x:Int = none // uninitialized but not an optional
> >
> > print(x) // run-time error as x is uninitialized
> >
> > if x == nil { … } // compile time error… x can never be nil because it
> is not an optional
> >
> > if x == none { x = 2 } // … but it can be uninitialized
> >
> > Optionals can also be uninitialized:
> >
> > var y:Int? = none // uninitialized and an optional
> >
> > if y == nil { … } // run-time error as y is uninitialized
> >
> > y = nil
> >
> > if y == nil { … } // fine
>
> I think there *may* be a case for this as a strictly static check. That
> is, setting a variable to `none` would be a way to explicitly mark the
> current state as invalid, and ask the compiler to prove that it's not used
> again until you've reinitialized it. But your example of `x == none` would
> not make any sense—`none` would not be a thing that existed at runtime.
> That's a very niche feature, though, and I'd need convincing that it's
> helpful.
>
> I'm strongly opposed to this feature as a runtime construct. It's
> basically just reintroducing null references, which is an anti-goal.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 
Best Regards!

Yang Wu
--------------------------------------------------------
Location: Pudong, Shanghai, China.
EMail    : pinxue at gmail.com
Website: http://www.time2change.mobi http://rockplayer.com
Twitter/Weibo : @pinxue
<http://www.pinxue.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160109/61fcd795/attachment.html>