> On 7 Nov 2016, at 11:58, Charlie Monroe <char...@charliemonroe.net> wrote:
>
> I'd personally not make this automatic, but require explicit action from the
> developer.
>
> In case of nullability, I have previously suggested "nonnil" keyword:
>
> let foo: String? = "Hello World"
> guard nonnil foo else {
> return
> }
>
> In which way you explicitly request the type narrowing. Or:
>
> let foo: Any
> guard foo as String else {
> return
> }
>
> I.e. not using "is" which returns a boolean, but using the cast operator,
> which IMHO makes more sense and prevents from unintentional type narrowing…
Normally I'm a proponent of being more rather than less explicit, but the
biggest draw of type-narrowing to me is that you're *already* telling the
type-checker, it's really just confirming what you know automatically.
So if I do:
if foo is String {
// Do lots of non-string stuff
(foo as String).somethingStringSpecific
}
On the last line of the block the type-checker is able to remind me that I
already know that foo is a String, so I don't need to cast it.
Really when it comes down to it the type-narrowing never takes anything away
from you; you can always handle the value as a less specific (wider) type if
you want to, but if you want to treat it like a String because you know it's
one, then you can do that too.
I'm concerned that if the feature had to be explicit, it would lack
discoverability, and really the point is almost to get rid of the need to do
things explicitly when you don't need to. It's like type inference on overdrive
in a way.
I guess I just don't see why you'd think that "guard nonnil foo" is really more
explicit than "guard foo != nil", in both cases you know that foo can't be nil
past that point, so is a new keyword really justified?_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
