[swift-evolution] [Proposal] Type Narrowing

[T.J. Usiyan]

I am mostly opposed because I don't see how this could avoid being
complicated to explain compiler magic. Making this accessible as a feature
for our types and operations would be a challenge and doesn't look to have
a worthwhile yield for the effort. We can accomplish most, if not all, of
this with shadowing.

TJ

On Mon, Nov 7, 2016 at 2:03 PM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On 7 Nov 2016, at 16:29, Charlie Monroe <charlie at charliemonroe.net>
> wrote:
> > I'm simply worried a little about unwanted effects and additional
> compiler "cleverness".
>
> I don't believe there should be any; either the type is narrowed or it
> isn't, if you rely on it being a type the type-checker can't verify, you'll
> get an error, otherwise you won't. There shouldn't be scope for anything
> unexpected.
>
> > Xcode's migration is "nice", but I'd like to point out that migration to
> Swift 3 of my project took 6 hours (!) and I spent almost 2 more days
> manually changing what the migrator didn't manage to do on its own. And
> that was one of my projects. I really don't want to go through this once
> more.
>
> I agree, but the only code that should be affected by this is code where
> there is unwrapping that can be determined to either be redundant, or is
> definitely incorrect; in the former case it will only be a warning (so you
> can remove force unwrapping that is no longer needed) and in the latter it
> will be an error because the type-checker has actually identified something
> that will definitely cause a run-time error.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161107/e0a66643/attachment.html>