[Proposal draft] Use obtain let instead if let construction

Carlos_Garcia · January 8, 2017, 2:46am

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

thislooksfun · January 8, 2017, 3:12am

-1 from me, I think that it makes perfect sense the way it is.

More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..."
I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems like it would be getting something from somewhere else, not always locally, maybe use an `unwrap` keyword in there somewhere, if you want it to be very clear what's happening?

-thislooksfun (tlf)

···

On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

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

codafi · January 8, 2017, 7:11am

-1. This proposal is, in fact, cosmetic and has no impact on matters related to the ABI. Moreover it is a breaking change that would require migration of a lot of existing code without significant justification.

A verb in this position is far more confusing than a logical connective. `obtain` and similar imply that the statement attempts to move a value out of a container, which is perhaps the wrong image here, and does not elucidate control flow. "So I've obtained a value, what then? Where does the flow of control reach next?"

If beginners are confused about the optional unwrapping process, even after reading the many parts of the Swift book that offer examples of its use cases and semantics, then I would be more concerned. But I'm not inclined to believe it's enough to warrant a change this large at this time.

~Robert Widmann

2017/01/07 19:46、Carlos García via swift-evolution <swift-evolution@swift.org> のメッセージ:

···

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

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

Javi · January 8, 2017, 4:45am

Based on your examples I think you were thinking about the "guard" keyword,
instead of "if"?

`If let foo = bar else` is not a valid construction. `if let foo = bar { }
else {}` may have been what you meant, but in this case it is clear that
this is just like a regular if, combined with unwrapping an optional.

···

On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution < swift-evolution@swift.org> wrote:

-1 from me, I think that it makes perfect sense the way it is.

More specifically, I read `if let safe = optional` as "if optional can be
unwrapped into safe, then ..."
I think `obtain let` is more confusing, as it's not clear that it's a
conditional from that keyword. Plus to me, "obtain" seems like it would be
getting something from somewhere else, not always locally, maybe use an
`unwrap` keyword in there somewhere, if you want it to be very clear what's
happening?

-thislooksfun (tlf)

On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

Here’s a draft proposal to change *if let* construction for *obtain let*. Proposal is at:

https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "*Effect on ABI stability*" and "*Effect on API resilience*" points

Carlos

_______________________________________________
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

--
Javier Soto

Carlos_Garcia · January 8, 2017, 7:24am

Hi Robert,

ok, I agree with you `obtain` could be bad replacement, that's why it's a draft. I’m not a native english speaker.
In any case I’ve not problem the way it is now.

Best
Carlos

···

On 08 Jan 2017, at 08:11, Robert Widmann <devteam.codafi@gmail.com> wrote:

-1. This proposal is, in fact, cosmetic and has no impact on matters related to the ABI. Moreover it is a breaking change that would require migration of a lot of existing code without significant justification.

A verb in this position is far more confusing than a logical connective. `obtain` and similar imply that the statement attempts to move a value out of a container, which is perhaps the wrong image here, and does not elucidate control flow. "So I've obtained a value, what then? Where does the flow of control reach next?"

If beginners are confused about the optional unwrapping process, even after reading the many parts of the Swift book that offer examples of its use cases and semantics, then I would be more concerned. But I'm not inclined to believe it's enough to warrant a change this large at this time.

~Robert Widmann

2017/01/07 19:46、Carlos García via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Anton_Zhilin · January 8, 2017, 8:51am

-1 to obtain, unwrap and such.
+1 to removing optional pattern in favor of normal if-pattern, plus
removing case:

if let unwrapped? = optionalValue { ... }

gmosx · January 8, 2017, 12:58pm

I quite really like the `if let` syntax, feels natural to me.

-1

Rod_Brown · January 8, 2017, 6:22am

-1.

Your proposal seems to confuse something we already have in the language to handle unwrapping and guarding, to only proceed if the item is non-null: Guard.

We already have a keyword and behaviour that you specify in the “guard” behaviour.

Additionally, changing “guard” to be “obtain” would require “obtain” to be signficantly better than the “guard” wording - instead, it is significantly worse.

···

On 8 Jan 2017, at 1:46 pm, Carlos García via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

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

jeremyp · January 9, 2017, 10:32am

For me the link is broken and your GitHub account doesn’t seem to contain a clone of Swift-Evolution.

···

On 8 Jan 2017, at 03:46, Carlos García via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

Here’s a draft proposal to change
if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "
Effect on ABI stability" and "Effect on API resilience
" points

Carlos

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

Carlos_Garcia · January 8, 2017, 6:45am

Hi Rod,

Maybe I’m not explain correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement.

Best,
Carlos

···

On 08 Jan 2017, at 07:22, Rod Brown <rodney.brown6@icloud.com> wrote:

-1.

Your proposal seems to confuse something we already have in the language to handle unwrapping and guarding, to only proceed if the item is non-null: Guard.

We already have a keyword and behaviour that you specify in the “guard” behaviour.

Additionally, changing “guard” to be “obtain” would require “obtain” to be signficantly better than the “guard” wording - instead, it is significantly worse.

On 8 Jan 2017, at 1:46 pm, Carlos García via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Carlos_Garcia · January 8, 2017, 6:46am

Hi Javier,

Maybe I’m not explained correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement.

Best,
Carlos

···

On 08 Jan 2017, at 05:45, Javier Soto <javier.api@gmail.com> wrote:

Based on your examples I think you were thinking about the "guard" keyword, instead of "if"?

`If let foo = bar else` is not a valid construction. `if let foo = bar { } else {}` may have been what you meant, but in this case it is clear that this is just like a regular if, combined with unwrapping an optional.
On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 from me, I think that it makes perfect sense the way it is.

More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..."
I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems like it would be getting something from somewhere else, not always locally, maybe use an `unwrap` keyword in there somewhere, if you want it to be very clear what's happening?

-thislooksfun (tlf)

On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

Carlos_Garcia · January 8, 2017, 7:07am

I just realized my mistake in the example, I've corrected it

···

On 08 Jan 2017, at 07:45, Carlos García <carlosypunto@gmail.com> wrote:

Hi Rod,

Maybe I’m not explain correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement.

Best,
Carlos

On 08 Jan 2017, at 07:22, Rod Brown <rodney.brown6@icloud.com <mailto:rodney.brown6@icloud.com>> wrote:

-1.

Your proposal seems to confuse something we already have in the language to handle unwrapping and guarding, to only proceed if the item is non-null: Guard.

We already have a keyword and behaviour that you specify in the “guard” behaviour.

Additionally, changing “guard” to be “obtain” would require “obtain” to be signficantly better than the “guard” wording - instead, it is significantly worse.

On 8 Jan 2017, at 1:46 pm, Carlos García via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Derrick_Ho · January 8, 2017, 7:26pm

*if let *is fine the way it currently is. It may be strange to newcomers
since it is unique, but once you get used to it, it is super useful.

···

On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote:

I quite really like the `if let` syntax, feels natural to me.

-1

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

Carlos_Garcia · January 8, 2017, 7:07am

I just realized my mistake in the example, I've corrected it

···

On 08 Jan 2017, at 07:46, Carlos García <carlosypunto@gmail.com> wrote:

Hi Javier,

Maybe I’m not explained correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement.

Best,
Carlos

On 08 Jan 2017, at 05:45, Javier Soto <javier.api@gmail.com <mailto:javier.api@gmail.com>> wrote:

Based on your examples I think you were thinking about the "guard" keyword, instead of "if"?

`If let foo = bar else` is not a valid construction. `if let foo = bar { } else {}` may have been what you meant, but in this case it is clear that this is just like a regular if, combined with unwrapping an optional.
On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
-1 from me, I think that it makes perfect sense the way it is.

More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..."
I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems like it would be getting something from somewhere else, not always locally, maybe use an `unwrap` keyword in there somewhere, if you want it to be very clear what's happening?

-thislooksfun (tlf)

On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

Here’s a draft proposal to change if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "Effect on ABI stability" and "Effect on API resilience" points

Carlos

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution
--
Javier Soto

griotspeak · January 9, 2017, 2:48am

-1 from me.
It doesn't really pay for itself.

···

On Sun, Jan 8, 2017 at 2:26 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote:

*if let *is fine the way it currently is. It may be strange to newcomers
since it is unique, but once you get used to it, it is super useful.

On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution < > swift-evolution@swift.org> wrote:

I quite really like the `if let` syntax, feels natural to me.

-1

_______________________________________________
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

Rien · January 8, 2017, 7:18am

-1, ‘obtain' obfuscates the meaning of the “if” statement. Since it would (conceptually) introduce a new statement that is very similar to the ‘if’ statement and ‘guard’ statement it would probably cause even more confusion.

Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: Swiftrien (Rien) · GitHub
Project: http://swiftfire.nl

···

On 08 Jan 2017, at 08:07, Carlos García via swift-evolution <swift-evolution@swift.org> wrote:

I just realized my mistake in the example, I've corrected it

On 08 Jan 2017, at 07:46, Carlos García <carlosypunto@gmail.com> wrote:

Hi Javier,

Maybe I’m not explained correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement.

Best,
Carlos

On 08 Jan 2017, at 05:45, Javier Soto <javier.api@gmail.com> wrote:

Based on your examples I think you were thinking about the "guard" keyword, instead of "if"?

`If let foo = bar else` is not a valid construction. `if let foo = bar { } else {}` may have been what you meant, but in this case it is clear that this is just like a regular if, combined with unwrapping an optional.
On Sat, Jan 7, 2017 at 7:12 PM thislooksfun via swift-evolution <swift-evolution@swift.org> wrote:
-1 from me, I think that it makes perfect sense the way it is.

More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..."
I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems like it would be getting something from somewhere else, not always locally, maybe use an `unwrap` keyword in there somewhere, if you want it to be very clear what's happening?

-thislooksfun (tlf)

On Jan 7, 2017, at 8:46 PM, Carlos García via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

Here’s a draft proposal to change
if let construction for obtain let. Proposal is at:
https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/XXXX-Use-obtain-let-instead-if-let-constructions.md

I would like to see what you think and get help with "
Effect on ABI stability" and "Effect on API resilience
" points

Carlos

_______________________________________________
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
--
Javier Soto

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