> On Nov 7, 2016, at 8:03 PM, Haravikk <[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.
True.
I'm simply worried about the compiler speed in general, that's what I meant by
"cleverness". The implicit variable typing and other features of Swift already
IMHO make it incredibly slow and various features analyzing the code in order
to determine the correct type can slow it even further. For comparison, a
100KLOC project of mine in pure Swift takes about 8 minutes to compile, vs. 3
minutes when it was in ObjC. With no optimizations turned on.
But I agree that designing a language around the compiler speed is wrong, but I
believe designing the language without taking it into account is just as wrong.
It's not worth designing features that would make the compilation so slow it
would render the language unusable.
Note that I have only very limited experience with compiler implementation,
I've only made a few minor things with Clang a few years back, so please feel
free to correct me.
>> 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.
There are two cases:
if foo != nil {
foo!.doSomething()
}
Currently, accessing a non-optional value with ! produces an error:
let foo = Bar()
foo!.doSomething() // ERROR
Second:
if foo != nil {
// Using ? to be extra cautious, if foo is var
foo?.doSomething()
}
This again currently produces an error:
let foo = Bar()
foo?.doSomething() // ERROR
Which is generally, what would semantically happen - the variable would loose
it optionality. Or am I wrong?
Which would require migration, where within all scopes, where you check if a a
variable is not nil, it removes all ? and !...
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
