allowing to specify optionality with type inference

Hugues_Bernet-Rollan · March 24, 2016, 10:22am

In a strongly typed language, such as Swift is, type inference is greatly
appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the type
of `aString` by the return type of `String.init()`


let aString = String()

Optional are generic enum which can contain a value of a generic type or nil
(https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift\)

Sometime you may want specify that the instance is of type optional in which
even if you are a the same time assigning a value to this instance.

In which case you loose the type inference mechanism and you have to define
both (the optionality as well as the type).

For example, you may want specify an optional String with a default value.


var a:String? = String()

// or

var b = String() as String?

// or

var c:Optional&lt;String&gt; = String()

But the compiler can already infer the variable type from this assignment, it
just miss the "optionality" of the variable.

It would be nice to be able to express this.

Then for, I propose the following syntax evolution:


var a:? = String()

// and/or (not recommended because more prone to typo and unclear...)

var a = String() as?

This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-
inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

\--

hugues@xdev.fr

http://www.linkedin.com/in/huguesbr

trs · March 24, 2016, 10:42am

Sorry, but I don't see an advantage over the current form. Introducing a new syntactical variant just to be able to drop the type name does not pull its own weight IMO.

-Thorsten

···

Am 24.03.2016 um 11:22 schrieb Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org>:

In a strongly typed language, such as Swift is, type inference is greatly appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or nil (https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift\)

Sometime you may want specify that the instance is of type optional in which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this assignment, it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:
https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--
hugues@xdev.fr
http://www.xdev.fr
http://www.linkedin.com/in/huguesbr
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Dan_Raviv · March 24, 2016, 10:55am

Hi Hughes,

What's wrong with:
let s = Optional(String("abc"))

···

On Thu, Mar 24, 2016 at 12:22 PM, Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org> wrote:

In a strongly typed language, such as Swift is, type inference is greatly
appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the
type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or
nil (
https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift
)

Sometime you may want specify that the instance is of type optional in
which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to
define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this assignment,
it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--

hugues@xdev.fr

http://www.xdev.fr

http://www.linkedin.com/in/huguesbr

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

Andrew · March 24, 2016, 10:40am

Hi Huges,

You can achieve a very similar result like this:

let x = 123

let y: Optional = x

The generic arguments can be inferred in more complicated cases too, for
example:

let z: Set = [1, 2, 3]

Which creates a Set<Int> rather than an Array<Int>.

I hope this helps!

Andrew Bennett

···

On Thu, Mar 24, 2016 at 9:22 PM, Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org> wrote:

In a strongly typed language, such as Swift is, type inference is greatly
appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the
type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or
nil (
https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift
)

Sometime you may want specify that the instance is of type optional in
which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to
define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this assignment,
it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--

hugues@xdev.fr

http://www.xdev.fr

http://www.linkedin.com/in/huguesbr

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

Erica_Sadun · March 31, 2016, 2:21pm

When I need to force an optional (primarily for sample code) I can do this already:

var myOptionalString = Optional("")

In this example, `myOptionalString ` picks up the type as well as the optionality.
Does this not meet your requirement of "Allowing to specify only the optionality part of
a variable type while still having the actual wrapped type infered by the assignement" in existing
Swift?

Beyond that, can you offer any compelling use-cases that motivate this change?

-- E

···

On Mar 24, 2016, at 4:22 AM, Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org> wrote:
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()

Radek_Pietruszewski · March 31, 2016, 11:46am

Could you give us one or two real-world examples where you’d want to do this?

I really can’t think of a situation where I would want to assign a non-optional to an optional variable. Even if I transform it later such that it might produce nil, it’s desirable to assign it to two different constants:

let a = String()
let b = a.thisMightMakeMeNil()

— Radek

···

On 24 Mar 2016, at 11:22, Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org> wrote:

In a strongly typed language, such as Swift is, type inference is greatly appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or nil (https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift\)

Sometime you may want specify that the instance is of type optional in which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this assignment, it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:
https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--
hugues@xdev.fr
http://www.xdev.fr

http://www.linkedin.com/in/huguesbr
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Hugues_Bernet-Rollan · March 24, 2016, 10:46am

Oh my,

I totally miss this one.

The generic one is pretty cool too.

You think the `?` shortcut could still make sense?

let y: ? = 123

Thanks!

Hugues BERNET-ROLLANDE

Hi Huges,

You can achieve a very similar result like this:

let x = 123

let y: Optional = x

The generic arguments can be inferred in more complicated cases too, for

example:

let z: Set = [1, 2, 3]

Which creates a Set<Int> rather than an Array<Int>.

I hope this helps!

Andrew Bennett

In a strongly typed language, such as Swift is, type inference is greatly

appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the

type of `aString` by the return type of `String.init()`

let aString = String()

Optional are generic enum which can contain a value of a generic type or

nil (<https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.s

)

Sometime you may want specify that the instance is of type optional in

which even if you are a the same time assigning a value to this instance.

In which case you loose the type inference mechanism and you have to define

both (the optionality as well as the type).

For example, you may want specify an optional String with a default value.

var a:String? = String()

// or

var b = String() as String?

// or

var c:Optional<String> = String()

But the compiler can already infer the variable type from this assignment,

it just miss the "optionality" of the variable.

It would be nice to be able to express this.

Then for, I propose the following syntax evolution:

var a:? = String()

// and/or (not recommended because more prone to typo and unclear...)

var a = String() as?

This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

<https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-

type-inference/proposals/0057-optionality-type-with-type-inference.md>

···

On Mar 24 2016, at 11:41 am, Andrew Bennett <cacoyi@gmail.com> wrote:
On Thu, Mar 24, 2016 at 9:22 PM, Hugues Bernet-Rollande via swift-evolution <[swift-evolution@swift.org](mailto:swift-evolution@swift.org)> wrote:

Let me know what you think.

Hugues BERNET-ROLLANDE

\--

[hugues@xdev.fr](mailto:hugues@xdev.fr)

<http://www.xdev.fr>

<http://www.linkedin.com/in/huguesbr>

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

Hugues_Bernet-Rollan · March 24, 2016, 10:57am

Hey All,

I think Andrew already nailed my proposal.

Thank you all.

Hugues BERNET-ROLLANDE

\--

hugues@xdev.fr

http://www.linkedin.com/in/huguesbr

Hi Hughes,

What's wrong with:

let s = Optional(String("abc"))

In a strongly typed language, such as Swift is, type inference is greatly

appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the

type of `aString` by the return type of `String.init()`

let aString = String()

Optional are generic enum which can contain a value of a generic type or

nil (<https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.s

)

Sometime you may want specify that the instance is of type optional in

which even if you are a the same time assigning a value to this instance.

In which case you loose the type inference mechanism and you have to define

both (the optionality as well as the type).

For example, you may want specify an optional String with a default value.

var a:String? = String()

// or

var b = String() as String?

// or

var c:Optional<String> = String()

But the compiler can already infer the variable type from this assignment,

it just miss the "optionality" of the variable.

It would be nice to be able to express this.

Then for, I propose the following syntax evolution:

var a:? = String()

// and/or (not recommended because more prone to typo and unclear...)

var a = String() as?

This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

<https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-

type-inference/proposals/0057-optionality-type-with-type-inference.md>

···

On Mar 24 2016, at 11:56 am, Dan Raviv <dan.raviv@gmail.com> wrote:
On Thu, Mar 24, 2016 at 12:22 PM, Hugues Bernet-Rollande via swift-evolution <[swift-evolution@swift.org](mailto:swift-evolution@swift.org)> wrote:

Let me know what you think.

Hugues BERNET-ROLLANDE

\--

[hugues@xdev.fr](mailto:hugues@xdev.fr)

<http://www.xdev.fr>

<http://www.linkedin.com/in/huguesbr>

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

Qbyte · March 27, 2016, 7:13pm

Only to be complete:

let str1 = String?() // nil
let str2 = String?("") // ""

Kind regards
- Maximilian

···

Am 24.03.2016 um 11:57 schrieb Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org>:

Hey All,

I think Andrew already nailed my proposal.

Thank you all.

Hugues BERNET-ROLLANDE

--
hugues@xdev.fr
http://www.xdev.fr
http://www.linkedin.com/in/huguesbr
On Mar 24 2016, at 11:56 am, Dan Raviv <dan.raviv@gmail.com> wrote:
Hi Hughes,

What's wrong with:
let s = Optional(String("abc"))

On Thu, Mar 24, 2016 at 12:22 PM, Hugues Bernet-Rollande via swift-evolution <swift-evolution@swift.org> wrote:
In a strongly typed language, such as Swift is, type inference is greatly appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or nil (https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift\)

Sometime you may want specify that the instance is of type optional in which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this assignment, it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:
https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--
hugues@xdev.fr
http://www.xdev.fr
http://www.linkedin.com/in/huguesbr

_______________________________________________
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

Hugues_Bernet-Rollan · March 31, 2016, 3:34pm

Hey All,

I think Andrew already pointed out the solution.

In first place I wasn't sure if there was a syntax to express the Optionality
of a variable while keeping the inference type.

I was just suggesting to use the "?" syntax to do so:


// Optional string  with an existing without declaring a specific type except
it's optionality, gaining for free the String type inference

var c: ? = "I could become nil"

But Andrew pointed out that an alternative syntax already exist:


var a: Optional = "I could become nil"  
var b:Optional&lt;String&gt; = "me too"

And thanks to Erika, another one:


let c = Optional("Also me, thanks to Erika")

I think it could still make sense to allow the "?" syntax previously
described, as it is more synthetic than the other one and match the Optional
usage (with "?") and could also be completed with a "!" syntax:


// Optional String with an existing value as a String using inference type

var e:? = "I'm a synthetic version of the above"

// equivalent of

var f: Optional =  "I'm a synthetic version of the above"

// Unwrapped Optional with an existing as a String using inference type

var g:! = "I could be nil but will crash if access directly"

// equivalent of

var h:Optional = "I could be nil but will crash if access directly"

To close (or open for who wants to) this debate, I think Optional have already
enough syntax.

Hugues

var a:String? = String()

// or

var b = String() as String?

// or

var c:Optional<String> = String()

When I need to force an optional (primarily for sample code) I can do this

already:

var myOptionalString = Optional("")

In this example, `myOptionalString ` picks up the type as well as the

optionality.

Does this not meet your requirement of "_Allowing to specify only the

optionality part of _

_a variable type __while still having the actual wrapped type infered by the

assignement_" in existing

Swift?

Beyond that, can you offer any compelling use-cases that motivate this

change?

···

On Mar 31 2016, at 4:22 pm, Erica Sadun <erica@ericasadun.com> wrote:

On Mar 24, 2016, at 4:22 AM, Hugues Bernet-Rollande via swift-evolution &lt ;[swift-evolution@swift.org](mailto:swift-evolution@swift.org)> wrote:

\-- E

jtbandes · March 27, 2016, 11:19pm

I think it would make sense if a postfix "?" would make the variable
optional:

var x = "some string"?
x = nil // allowed because x has type Optional<String>

This parallels the optional pattern: `if case "foo"? = x { ... }`

Jacob

···

On Sun, Mar 27, 2016 at 3:13 PM, Maximilian Hünenberger < swift-evolution@swift.org> wrote:

Only to be complete:

let str1 = String?() // nil
let str2 = String?("") // ""

Kind regards
- Maximilian

Am 24.03.2016 um 11:57 schrieb Hugues Bernet-Rollande via swift-evolution < > swift-evolution@swift.org>:

Hey All,

I think Andrew already nailed my proposal.

Thank you all.

Hugues BERNET-ROLLANDE

--

hugues@xdev.fr

http://www.xdev.fr

http://www.linkedin.com/in/huguesbr
On Mar 24 2016, at 11:56 am, Dan Raviv <dan.raviv@gmail.com> wrote:
Hi Hughes,

What's wrong with:
let s = Optional(String("abc"))

On Thu, Mar 24, 2016 at 12:22 PM, Hugues Bernet-Rollande via >> swift-evolution <swift-evolution@swift.org> wrote:

In a strongly typed language, such as Swift is, type inference is greatly
appreciated as it declutter the instance type definition.

For example, in the following statement, the compiler easily deduct the
type of `aString` by the return type of `String.init()`
let aString = String()
Optional are generic enum which can contain a value of a generic type or
nil (
https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift
)

Sometime you may want specify that the instance is of type optional in
which even if you are a the same time assigning a value to this instance.
In which case you loose the type inference mechanism and you have to
define both (the optionality as well as the type).
For example, you may want specify an optional String with a default value.
var a:String? = String()
// or
var b = String() as String?
// or
var c:Optional<String> = String()
But the compiler can already infer the variable type from this
assignment, it just miss the "optionality" of the variable.
It would be nice to be able to express this.

Then for, I propose the following syntax evolution:
var a:? = String()
// and/or (not recommended because more prone to typo and unclear...)
var a = String() as?
This would allow for more synthetic optional declaration.

I've draft a proposal on my `swift-evolution` fork:

https://github.com/huguesbr/swift-evolution/blob/optionality-type-with-type-inference/proposals/0057-optionality-type-with-type-inference.md

Let me know what you think.

Hugues BERNET-ROLLANDE

--

hugues@xdev.fr

http://www.xdev.fr

http://www.linkedin.com/in/huguesbr

_______________________________________________
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

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