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 < [email protected]> wrote: > > > On 7 Nov 2016, at 16:29, Charlie Monroe <[email protected]> > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
