Proposal Draft: Optional Upgrading Assignment


(Paul Ossenbruggen) #1

Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.


(Dave Abrahams) #2

Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the
very next line I must specify the type.

These work:

let y: Optional = x
let z = Optional(x)

···

on Thu Feb 04 2016, Paul Ossenbruggen <swift-evolution@swift.org> wrote:

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It
follows the same conventions as var and let that currently exist in
the language.

The advantages: this is easier to read, more compact, and lets type
inference determine the type.

If let and other conditionals would not support this syntax and
optionals of optionals is not supported. So let x?? = y would not
result in an optional optional. Also if y was an optional it would not
let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because
if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

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

--
-Dave


(Félix Cloutier) #3

Second option: use `let y = Optional(x)`.

Félix

···

Le 4 févr. 2016 à 03:28:09, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> a écrit :

Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

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


(Radek Pietruszewski) #4

What’s your use case for this? I don’t find myself doing this very often.

And when I do, Optional(x) does the job.

Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

let x = “Some Value”
let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

## Proposal

I propose the following syntax:

let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions asvarandletthat currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If letand other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

let optionalValue? = value

This would not make sense in theif let, (guardlet)context becauseif letunwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires thecasekeyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

— Radek


(Chris Lattner) #5

This syntax already means something in Swift (though in this context it is illegal): "a?” is a pattern that binds to the inside of an optional. It actually does the opposite of what you propose: it binds “a” to the thing inside an optional, which is the opposite of what you want.

As others have pointed out, using "Optional(x)” works today in an arbitrary expression position.

-Chris

···

On Feb 4, 2016, at 12:28 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

## Proposal

I propose the following syntax:

  let y? = x


(Allen Ding) #6

*Draft Proposal feedback welcome.*

*## Introduction*

Currently to make a optional from a value the type name must be repeated:

let x = “Some Value”
let y : String? = x

This takes away some of the advantage of type inference because the very
next line I must specify the type.

Any use case examples? I've been trying to figure out why is this needs
fixing (I don't even see it as a problem).

···

On Thu, Feb 4, 2016 at 4:28 PM, Paul Ossenbruggen via swift-evolution < swift-evolution@swift.org> wrote:

*## Proposal*

I propose the following syntax:

let y? = x

This binds a new optional y which wraps the same value of x. It follows
the same conventions as *var* and *let* that currently exist in the
language.

The advantages: this is easier to read, more compact, and lets type
inference determine the type.

*If let* and other conditionals would not support this syntax and
optionals of optionals is not supported. So let x?? = y would not result in
an optional optional. Also if y was an optional it would not let you
upgrade that.

*## Detailed Design*

The grammar:

let optionalValue? = value

This would not make sense in the *if let, (guard** let)* context because *if
let* unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the *case*
keyword.

Wrapping optional in an optional is an error.

*## Impact on existing code*

The current syntax will continue to exist so it will have no impact on
existing code.

*## Alternatives Considered*

None.

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


(Paul Ossenbruggen) #7

Just sugar for that, plus there is symmetry to this proposal, it is more discoverable, and it is more concise.

···

On Feb 4, 2016, at 1:57 AM, Taras Zakharko <taras.zakharko@uzh.ch> wrote:

-1 from me

  let x = Optional(“Some Value”)

does the job just fine, is very clean, and I don’t see any reason to shorten it.

— Taras

On 04 Feb 2016, at 10:33, Allen Ding via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Feb 4, 2016 at 4:28 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

Any use case examples? I've been trying to figure out why is this needs fixing (I don't even see it as a problem).

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

_______________________________________________
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


(Paul Ossenbruggen) #8

I did consider this but I think it would be too easy to accidentally upgrade an optional. When you may have been thinking you were dealing with an optional and you needed to chain them.

···

On Feb 4, 2016, at 7:45 AM, Jerome ALVES <j.alves@me.com> wrote:

Maybe allowing optional chaining here is the best option ?

let test = "Test" // String
let testOrNil = test? // String?

- Jérôme

Le 4 févr. 2016 à 16:32, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Just sugar for that, plus there is symmetry to this proposal, it is more discoverable, and it is more concise.

On Feb 4, 2016, at 1:57 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

-1 from me

  let x = Optional(“Some Value”)

does the job just fine, is very clean, and I don’t see any reason to shorten it.

— Taras

On 04 Feb 2016, at 10:33, Allen Ding via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Feb 4, 2016 at 4:28 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

Any use case examples? I've been trying to figure out why is this needs fixing (I don't even see it as a problem).

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

_______________________________________________
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

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


(Paul Ossenbruggen) #9

Ok if it conflicts then that is a good reason to not do this.

···

Sent from my iPhone

On Feb 4, 2016, at 9:35 AM, Chris Lattner <clattner@apple.com> wrote:

## Proposal

I


(Taras Zakharko) #10

-1 from me

  let x = Optional(“Some Value”)

does the job just fine, is very clean, and I don’t see any reason to shorten it.

— Taras

···

On 04 Feb 2016, at 10:33, Allen Ding via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Feb 4, 2016 at 4:28 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

Any use case examples? I've been trying to figure out why is this needs fixing (I don't even see it as a problem).

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

_______________________________________________
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


(Jerome ALVES) #11

Maybe allowing optional chaining here is the best option ?

let test = "Test" // String
let testOrNil = test? // String?

- Jérôme

···

Le 4 févr. 2016 à 16:32, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> a écrit :

Just sugar for that, plus there is symmetry to this proposal, it is more discoverable, and it is more concise.

On Feb 4, 2016, at 1:57 AM, Taras Zakharko <taras.zakharko@uzh.ch <mailto:taras.zakharko@uzh.ch>> wrote:

-1 from me

  let x = Optional(“Some Value”)

does the job just fine, is very clean, and I don’t see any reason to shorten it.

— Taras

On 04 Feb 2016, at 10:33, Allen Ding via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Feb 4, 2016 at 4:28 PM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Draft Proposal feedback welcome.

## Introduction

Currently to make a optional from a value the type name must be repeated:

  let x = “Some Value”
  let y : String? = x

This takes away some of the advantage of type inference because the very next line I must specify the type.

Any use case examples? I've been trying to figure out why is this needs fixing (I don't even see it as a problem).

## Proposal

I propose the following syntax:

  let y? = x

This binds a new optional y which wraps the same value of x. It follows the same conventions as var and let that currently exist in the language.

The advantages: this is easier to read, more compact, and lets type inference determine the type.

If let and other conditionals would not support this syntax and optionals of optionals is not supported. So let x?? = y would not result in an optional optional. Also if y was an optional it would not let you upgrade that.

## Detailed Design

The grammar:

  let optionalValue? = value

This would not make sense in the if let, (guard let) context because if let unwraps the value, so this would be an error.

This should not conflict with pattern matching as that requires the case keyword.

Wrapping optional in an optional is an error.

## Impact on existing code

The current syntax will continue to exist so it will have no impact on existing code.

## Alternatives Considered

None.

_______________________________________________
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

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


#12

Although the "reverse" syntax others pointed out fits better. Especially as symmetry to optional pattern matching:

let num = 1? // Int?

if case let n? = num {
    n // Int
    n? // Int? since it is equal to "num" (why would someone use it here?)
}

But I doubt it is worth implementing only due to symmetry reasons.

The only real use I can imagine would be in conjunction with xxxLiterals.

Therefore -0.5 for this proposal.

- Maximilian

···

Am 04.02.2016 um 18:42 schrieb Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org>:

Ok if it conflicts then that is a good reason to not do this.

Sent from my iPhone

On Feb 4, 2016, at 9:35 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

## Proposal

I

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