Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Patrick Gili via swift-evolution]

> 
>   * What is your evaluation of the proposal?

The IUO is not a transitional technology, as it is essential to bridge from 
languages from which Swift evolved, such as C and Objective-C. The proposal 
doesn't give much consideration to this application of IUOs, and hence, I 
cannot support the proposal in its current state.

>   * Is the problem being addressed significant enough to warrant a change 
> to Swift?

Grant it, the use of IUO outside of bridging is strange and probably a poor 
practice. However, there seems to exist a requirement and this proposal would 
make satisfying this requirement more difficult.

>   * Does this proposal fit well with the feel and direction of Swift?

No.

>   * If you have you used other languages or libraries with a similar 
> feature, how do you feel that this proposal compares to those?

Not applicable.

>   * How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

In-depth study.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Bernd Ohr (jazzbox) via swift-evolution]

> * What is your evaluation of the proposal?

I don’t like the proposal.

> * Is the problem being addressed significant enough to warrant a change to 
> Swift?

I don't agree that IUOs are a transitional technology as long as there is an 
import of C libraries.

The only problem I see that IUO’s are being used where it is not necessary, 
either out of ignorance or convenience.

My counter proposal: IUO’s are only allowed (in pure Swift files) with private 
scope (filePrivate) and not with internal or public scope! In this way the 
uncontrolled spread of IUO’s can be most easily prevented.

An additional restriction could be that IUO’s are only allowed in files that 
import C or ObjC libraries.

> * Does this proposal fit well with the feel and direction of Swift?

No, because it makes the use of IUO’s much harder (IMHO) where it is really 
necessary.

> * If you have you used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

N/A

> * How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?

I read the proposal and had a look at some of my code that uses IUO’s 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Brent Royal-Gordon via swift-evolution]

> I do have a question. 
> 
> let x: Int! = 5
> let y = x
> 
> let a = x ?? 1 // would this still work? 
> Or would it auto unwrapping always? meaning when .some `a = 5` or crash when 
> .none? 
> I am assuming that x is `Int?` that autounwraps. Just curious if autounwraps 
> only happen on assignment like in `y = x`

I believe that, in this example, `y` is of type `Int?`, that is, a 
non-autounwrapped optional. An autounwrapped optional is only unwrapped if 
Swift cannot make the code type-check without unwrapping it.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Dave via swift-evolution]

I’m pretty sure I only use them with `@IBOutlet` vars.

One of the alternatives list is: 
• Remove IUOs completely. Untenable due to the prevalence of deferred 
initialization and unannotated Objective-C API in today's Swift ecosystem.

What about leaving IUOs in the compiler, but disallowing them unless the code 
is marked @objc (and treating them as `T?` in code that isn’t)? The stated 
motivation is "This proposal seeks to limit the adoption of IUOs to places 
where they are actually required, and put the Swift language on the path to 
removing implicitly unwrapped optionals from the system entirely when other 
technologies render them unnecessary.”… If they’re only intended to be used 
with C/Obj-C code, seems like that’s something that’d be possible for the 
compiler to enforce.

Having typed this all out, I’m starting to suspect it might be more complicated 
than what we have now… Hmm… I’ll hit send anyway, in case I’m wrong.

- Dave Sweeris

> On Mar 25, 2016, at 3:10 PM, Joseph Lord via swift-evolution 
>  wrote:
> 
> On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote:
>> Hello Swift community,
>> 
>> The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs 
>> through March 30th. The proposal is available here:
>> 
>>  
>> https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md
>> 
> 
> As I don't use IUO optionals I'm really fairly neutral on the proposal. I 
> just wanted to mention with the powerful tools we have for dealing with 
> optionals (optional, chaining, nil-coalescing, map, flatmap, guard, and let - 
> thanks Chris and team) it really would be quite feasible to do away with IUOs 
> completely. I don't think the community is ready for that yet so I'm not 
> proposing that course of action at this time but such a proposal wouldn't get 
> a universally hostile response.
> 
> Even force unwrap is something that I only do test code since flatmap was 
> added to the Standard Library (I used to have my own implementation of 
> flatmap with a force unwrap after a filter which was the only production use 
> I've put force unwrap to).
> 
> Joseph
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

[Joseph Lord via swift-evolution]

On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote:

Hello Swift community,

The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs 
through March 30th. The proposal is available here:


https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md



As I don't use IUO optionals I'm really fairly neutral on the proposal. 
I just wanted to mention with the powerful tools we have for dealing 
with optionals (optional, chaining, nil-coalescing, map, flatmap, guard, 
and let - thanks Chris and team) it really would be quite feasible to do 
away with IUOs completely. I don't think the community is ready for that 
yet so I'm not proposing that course of action at this time but such a 
proposal wouldn't get a universally hostile response.


Even force unwrap is something that I only do test code since flatmap 
was added to the Standard Library (I used to have my own implementation 
of flatmap with a force unwrap after a filter which was the only 
production use I've put force unwrap to).


Joseph
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution