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

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

[Антон Жилин via swift-evolution]

First of all, -1 for still not exposing @autounwrapped to the user as
discussed.
But there is a greater problem.

If we move from current type syntax to attribute syntax, we should remove
T!, because it can no longer be a type. Otherwise we will only bring more
inconsistency into the language.

But then you'll say @autounwrapped is too verbose to be used everywhere.

Let's be honest, we rarely use IUO in Swift (IBoutlet was noted).
Objective-C does not use T! syntax. So the goal is actually to reduce
syntactic noise in documentation of imported functions.

One solution could be to remove T! from Swift, but leave this notation for
documentation. Or brainstorm that and find another terse and readable
syntax.

> What is your evaluation of the proposal?
Right now, -2.

> Is the problem being addressed significant enough to warrant a change to
Swift?
Yes, compiler magic should be limited.

> Does this proposal fit well with the feel and direction of Swift?
Idea - yes, wording - no.

> If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
No languages that I know of have IUO.

> How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Followed and participated in the discussion.

- Anton
___
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

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

[Chris Lattner via swift-evolution]

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

Reviews are an important part of the Swift evolution process. All reviews 
should be sent to the swift-evolution mailing list at:
https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager.


What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. When 
writing your review, here are some questions you might want to answer in your 
review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change 
to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar 
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager



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