Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Vladimir.S via swift-evolution]

On 12.04.2017 15:35, Xiaodi Wu wrote:
As I explained on Twitter, the behavior is initially counterintuitive but in many 
ways the least surprising result.


(First, you are incorrect about P requiring a mutable property. That is not what var 
means in a protocol.)


Yes, sorry, my mistake. But actually this does not change anything for this 
example:

protocol P {
var value : Int32 {get set} // get+set
}

extension P {
var value : Int32 {get{return 10} set{}}
}

class C : P {
let value : Int = 4_000_000_000 // let constant
}




However, you are right that two properties named value are being allowed. It seems 
strange at first but consider:


Given: a protocol P with only one requirement, but with a default implementation for 
that requirement. One would expect that any type T could retroactively conform to P. 
After all, either T has its own implementation of the requirement or it does not.


If the requirement is a property and not a method, and T has an identically named but 
not identically typed property, we allow this sort of "overloading" which is very 
much like overloading on the return type. This fulfills the expectation above that T 
can conform to P. Even requiring a warning in this scenario would break retroactive 
conformance.


The behavior at the call site is not harmful. A user of T may or may not see that it 
conforms to P. This is because conformance can be retroactive. Thus, when using an 
instance of T, references to the property are to T's own implementation. However, if 
the user can see P and the conformance T : P, they can always explicitly request P's 
differently typed implementation explicitly by using "as" (just like selecting an 
overloaded method with a different return type).


The behavior that is unexpected and potentially harmful is for the author of a type T 
trying to conform to P. It falls into the category of near-misses that includes 
unintentional typos in method names, etc. It is no more surprising than any of those 
cases where you, say, get the argument label spelled slightly wrong and end up 
without an intended override of a default implementation but two methods instead.


Not agree here. We *can* have methods with the same name but different 
argument/result type defined in the *same* type.

But we can't have property with the same name but different type in the same 
type.



As mentioned earlier on this list, the user experience of writing a conforming type 
is suboptimal, and there are likely to be clever ways for the compiler or other tools 
to help. However, ripping out type inference or breaking retroactive conformance is 
not the way forward to solving this issue.


I agree that retroactive conformance is important feature, but in this particular 
case, the situation IMO is not the same as with near-miss for methods.


And actually I still believe that such near-miss(even for methods) will be usually an 
hidden/delayed error, when user do expect that type's methods/props will conform the 
type to protocol, not protocol's default method. And I do believe that be able to 
prevent such error is more important than no-worry retroactive conformance. (and then 
spent a number of hours to debug such hard-to-find bug)


Plus, if we *want* we can suggest a way to silence such warning even for retroactive 
conformance. The question if the problem worth to be solved.


On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution 
> wrote:


On 12.04.2017 7:19, Jaden Geller wrote:
 >
 >> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution
 >> 
>> 
wrote:
 >>
 >> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
 >>> Hi all,
 >>>
 >>> In a discussion about inferring parameter types from default value,
 >>> Slava brought up some performance problems caused by type inference for
 >>> stored properties in side types:
 >>>
 >>>

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 >>>
 >>> Towards the end, the post mentioned that some Swift team members
 >>> contemplated requiring types for stored properties in type 
declarations.
 >>> I think this idea deserves some more attention. Hence this last minute
 >>> idea-floating.
 >>>
 >>> In addition to solving a performance headache in implementation,
 >>> there're always the general benefit of making type declartion more
 >>> explicit and readable (clarity for reader should out-weigh pleasure of
 >>> the author). Making the language slightly more consistent (we are not
 >>> inferring types for default parameter values in function anyways).
 >>>
 >>> The cons for doing this are obvious too: the inference makes the
 >>> language feels more friendly 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Lucas Neiva via swift-evolution]

I think it’s worth thinking about, clarifying, and possibly documenting where 
inference happens and where it doesn’t.

As mentioned, there are limits to inference. Some of those limits are imposed 
by design, as in functions (check out F# to have your mind blown by how far 
type inference goes there).

- Type inference of function-local variable declarations is not the topic here. 
Everybody loves that :-D.

- For properties there are some levels to it, depending on the initial value:
  - [inferred] Literals (String, Int, ...)
  - [inferred] Constructor call, e.g. `Foo(a, b)`
  - [inferred] Function call without generics, e.g. `someFunc()`
  - [inferred] Function call with generics, e.g. 
`someArray.map(someGenericFunc)` (I believe this triggered the discussion, as 
it can cause performance issues)
  - [NOT inferred] Function call with AMBIGUOUS types (impossible to infer)
  - [NOT inferred] Closure, e.g. `{ /* do some stuff */ return /* some initial 
value */ }()`

- Computed properties, where currently the type is NOT inferred


- I’m unsure about how global properties are implemented, but I think the 
inference behaviour is the same there.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Xiaodi Wu via swift-evolution]

As I explained on Twitter, the behavior is initially counterintuitive but
in many ways the least surprising result.

(First, you are incorrect about P requiring a mutable property. That is not
what var means in a protocol.)

However, you are right that two properties named value are being allowed.
It seems strange at first but consider:

Given: a protocol P with only one requirement, but with a default
implementation for that requirement. One would expect that any type T could
retroactively conform to P. After all, either T has its own implementation
of the requirement or it does not.

If the requirement is a property and not a method, and T has an identically
named but not identically typed property, we allow this sort of
"overloading" which is very much like overloading on the return type. This
fulfills the expectation above that T can conform to P. Even requiring a
warning in this scenario would break retroactive conformance.

The behavior at the call site is not harmful. A user of T may or may not
see that it conforms to P. This is because conformance can be retroactive.
Thus, when using an instance of T, references to the property are to T's
own implementation. However, if the user can see P and the conformance T :
P, they can always explicitly request P's differently typed implementation
explicitly by using "as" (just like selecting an overloaded method with a
different return type).

The behavior that is unexpected and potentially harmful is for the author
of a type T trying to conform to P. It falls into the category of
near-misses that includes unintentional typos in method names, etc. It is
no more surprising than any of those cases where you, say, get the argument
label spelled slightly wrong and end up without an intended override of a
default implementation but two methods instead.

As mentioned earlier on this list, the user experience of writing a
conforming type is suboptimal, and there are likely to be clever ways for
the compiler or other tools to help. However, ripping out type inference or
breaking retroactive conformance is not the way forward to solving this
issue.
On Wed, Apr 12, 2017 at 05:15 Vladimir.S via swift-evolution <
swift-evolution@swift.org> wrote:

> On 12.04.2017 7:19, Jaden Geller wrote:
> >
> >> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution
> >> > wrote:
> >>
> >> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
> >>> Hi all,
> >>>
> >>> In a discussion about inferring parameter types from default value,
> >>> Slava brought up some performance problems caused by type inference for
> >>> stored properties in side types:
> >>>
> >>>
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> >>>
> >>> Towards the end, the post mentioned that some Swift team members
> >>> contemplated requiring types for stored properties in type
> declarations.
> >>> I think this idea deserves some more attention. Hence this last minute
> >>> idea-floating.
> >>>
> >>> In addition to solving a performance headache in implementation,
> >>> there're always the general benefit of making type declartion more
> >>> explicit and readable (clarity for reader should out-weigh pleasure of
> >>> the author). Making the language slightly more consistent (we are not
> >>> inferring types for default parameter values in function anyways).
> >>>
> >>> The cons for doing this are obvious too: the inference makes the
> >>> language feels more friendly and is, undoubtedly, a beloved feature for
> >>> many. This would be a source breaking change.
> >>>
> >>> Just thought I'd float the idea to gather some quick reaction. What do
> >>> y'all think?
> >>
> >> Although it seems like only an implementation-side problem(i.e. "let's
> just improve
> >> implementation"), I see a benefits to require type for stored property
> *if* it is
> >> not obvious what the type is for *reader*. I.e. if we have something
> like this, I
> >> don't think we should require a type:
> >> struct S {
> >>  var x = 0
> >> }
> >
> > I think there is value in requiring a type annotation there. For
> example, this bug
> > would be avoided:
> https://twitter.com/benjaminencz/status/851892622213783552
>
> I believe the pointed problem is much wider, than type-inference and I
> even think
> this is bug(in design?) that should be fixed at least with warning.
>
> Please consider this example:
>
> protocol P {
> var value : Int32 {get}
> }
>
> extension P {
> var value : Int32 {return 20}
> }
>
> class C : P {
> let value = 4_000_000_000
>
> /// or even this:
> // let value : Int = 4_000_000_000
> }
>
> First, as class C conforms to P protocol, it must have *mutable* 'value'
> property
> Second, currently it seems like class C has two 'value' properties with
> different
> type. It is very strange(the principle of less surprise, yes?) and as we
> can see
> dangerous behavior. Was bug to 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Vladimir.S via swift-evolution]

On 12.04.2017 7:19, Jaden Geller wrote:


On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution 
> wrote:


On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:

Hi all,

In a discussion about inferring parameter types from default value,
Slava brought up some performance problems caused by type inference for
stored properties in side types:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html

Towards the end, the post mentioned that some Swift team members
contemplated requiring types for stored properties in type declarations.
I think this idea deserves some more attention. Hence this last minute
idea-floating.

In addition to solving a performance headache in implementation,
there're always the general benefit of making type declartion more
explicit and readable (clarity for reader should out-weigh pleasure of
the author). Making the language slightly more consistent (we are not
inferring types for default parameter values in function anyways).

The cons for doing this are obvious too: the inference makes the
language feels more friendly and is, undoubtedly, a beloved feature for
many. This would be a source breaking change.

Just thought I'd float the idea to gather some quick reaction. What do
y'all think?


Although it seems like only an implementation-side problem(i.e. "let's just improve 
implementation"), I see a benefits to require type for stored property *if* it is 
not obvious what the type is for *reader*. I.e. if we have something like this, I 
don't think we should require a type:

struct S {
 var x = 0
}


I think there is value in requiring a type annotation there. For example, this bug 
would be avoided: https://twitter.com/benjaminencz/status/851892622213783552


I believe the pointed problem is much wider, than type-inference and I even think 
this is bug(in design?) that should be fixed at least with warning.


Please consider this example:

protocol P {
var value : Int32 {get}
}

extension P {
var value : Int32 {return 20}
}

class C : P {
let value = 4_000_000_000

/// or even this:
// let value : Int = 4_000_000_000
}

First, as class C conforms to P protocol, it must have *mutable* 'value' 
property
Second, currently it seems like class C has two 'value' properties with different 
type. It is very strange(the principle of less surprise, yes?) and as we can see 
dangerous behavior. Was bug to bugs.swift.org submitted? If so, what was the reply of 
the core team?






but I do think it will be better to require a type in such cases :

struct S{
 var x = something(SomeType(), 123, "123") // can be generic func
}





Daniel Duan ___
swift-evolution mailing listswift-evolut...@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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Víctor Pimentel Rodríguez via swift-evolution]

On Friday, April 7, 2017, Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi all,
>
> In a discussion about inferring parameter types from default value, Slava
> brought up some performance problems caused by type inference for stored
> properties in side types:
>
> https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170313/033882.html
>
> Towards the end, the post mentioned that some Swift team members
> contemplated requiring types for stored properties in type declarations. I
> think this idea deserves some more attention. Hence this last minute
> idea-floating.
>
> In addition to solving a performance headache in implementation, there're
> always the general benefit of making type declartion more explicit and
> readable (clarity for reader should out-weigh pleasure of the author).
> Making the
> language slightly more consistent (we are not inferring types for default
> parameter values in function anyways).
>
> The cons for doing this are obvious too: the inference makes the language
> feels more friendly and is, undoubtedly, a beloved feature for many. This
> would be a source breaking change.
>
> Just thought I'd float the idea to gather some quick reaction. What do
> y'all think?
>

I think this chabge would be too source breaking for Swift 4. Just for that
reason I would not implement it.

Also, I think the Core team talked about having specific themes for the
upcoming releases. I would very much like Swift 5 to have improving compile
times as a major theme.

Under such theme, maybe it makes sense to forbid complex expressions
in stored properties definitions with no explicit type. Forbidding literals
or direct function calls would remove a useful feature and the gains would
not be much, IMHO.

--
Víctor Pimentel

-- 

INNOVATION IN PERSONAL COMMS


*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimen...@tuenti.com

+34 914 294 039 <+34914294039> — +34 687 840 886 <+34687840886>
C/ Gran Vía, nº 28, 6ª planta — 28013 Madrid
Tuenti Technologies, S.L.

www.tu.com
www.tuenti.com
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Slava Pestov via swift-evolution]

> On Apr 9, 2017, at 3:01 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>   I generally dislike any language change desired because it makes the 
> compiler implementation easier. We saw a few such changes for Swift 3 and all 
> of them were net negatives for the actual users of the language (to a minor 
> extent for most, to be fair).

I’m going to have to call shenanigans on this claim :-) At least I can’t 
_think_ of any Swift 3 features that were designed with the goal of making the 
implementation simpler. Even the feature removals, such as nuking the ‘function 
currying’ syntax, took time to implement (and this is not even fully removed 
yet).

>  I would hope that, as the compiler matures, these types of inference 
> performance issues will become less of a problem. Removing a rather nice 
> language feature, especially one that plays such a big role in the “feel” of 
> the language, for short term gain seems rather shortsighted to me.

I agree. The type checker might have pathological behavior in some cases now, 
but we hope to fix those over time, and none of it is specific to the 
expressions people usually write in stored property initializers.

Slava

> 
> 
> 
> Jon Shier
> 
> 
>> On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution 
>> > wrote:
>> 
>> If inference only works in simple cases, I think it would seem like it works 
>> unpredictability to anyone unfamiliar with the implementation details.
>> 
>> I image the question of "why do I have to declare a type here, but not in 
>> this case?" coming up.
>> 
>> Declaring types is one of the first things you have to learn anyway. Just 
>> declaring a function already requires some understanding of types. 
>> Properties are not much different IMO.
>> 
>> On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
 > wrote:
 
 The cons for doing this are obvious too: the inference makes the language 
 feels more friendly and is, undoubtedly, a beloved feature for many. This 
 would be a source breaking change.
>>> 
>>> 
>>> Beyond just being more friendly, I think it could be considered a teaching 
>>> issue. A great way to introduce beginners to custom types would be 
>>> something like:
>>> 
>>> struct Point {
>>> var x = 0.0
>>> var y = 0.0
>>> }
>>> 
>>> Or:
>>> 
>>> struct Person {
>>> var name = ""
>>> var age = 18
>>> }
>>> 
>>> If you have to explicitly specify types for the properties, that's another 
>>> thing you need to introduce to people before you can do this.
>>> 
>>> On the other hand, a very limited form of inference might be fine here. 
>>> Imagine if we did a sort of limited, single-pass, top-down inference which 
>>> only understood a few things (literals, tuple syntax, initializer calls), 
>>> stopped once it had seen enough to infer a complete type, and rejected an 
>>> expression if it encountered something it didn't understand before 
>>> finishing. That would probably cover most simple cases, and it would 
>>> probably only allow expressions whose types were obvious enough that we 
>>> could use it for arguments, too. (But of course it would mean more code in 
>>> the compiler, so it might not be worth it.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> 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

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Sent from my iPhone

> On 12 Apr 2017, at 01:18, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate.

I think Swift and its compiler have. A lot of other strong points beyond type 
inference and emphasis on static typing too, but type inference has a very very 
real cost and sooner or later the language and its community will have to deal 
with compile times that are a lot slower (some people were reporting about 2+ 
times slower) than a similar project in Objective-C... that is a very real 
productivity cost.

> And here we're talking about removing this feature that was advertised from 
> the beginning as Swift's strong point, in order to make the compilation 
> faster? The compiler speeds will be improved, the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.
> 
> 
>> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
>> 
>>> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
>>>  wrote:
>>> 
>>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
>>> >  wrote:
>>> >
>>> > Hi all,
>>> >
>>> > In a discussion about inferring parameter types from default value, Slava 
>>> > brought up some performance problems caused by type inference for stored 
>>> > properties in side types:
>>> >
>>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> >
>>> > Towards the end, the post mentioned that some Swift team members 
>>> > contemplated requiring types for stored properties in type declarations. 
>>> > I think this idea deserves some more attention. Hence this last minute 
>>> > idea-floating.
>>> >
>>> > In addition to solving a performance headache in implementation, there're 
>>> > always the general benefit of making type declartion more explicit and 
>>> > readable (clarity for reader should out-weigh pleasure of the author). 
>>> > Making the
>>> > language slightly more consistent (we are not inferring types for default 
>>> > parameter values in function anyways).
>>> >
>>> > The cons for doing this are obvious too: the inference makes the language 
>>> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> > would be a source breaking change.
>>> >
>>> > Just thought I'd float the idea to gather some quick reaction. What do 
>>> > y'all think?
>>> 
>>> I’m willing to keep an open mind on this topic but I don’t think wholesale 
>>> banning of inference is the right thing to do.  Here is an example of a 
>>> case where I do not want to give up inference.  When a property is 
>>> initialized inline by calling an initializer of a non-generic type (very 
>>> common) any annotation is strictly redundant.
>>> 
>>> struct {
>>> let foo = Foo()
>>> }
>>> 
>>> Requiring a type annotation here feels very unnecessary and boilerplate-y.  
>>> I adds no additional clarity to a reader of the code, only noise.  Noise 
>>> reduces clarity.  Small amounts of unnecessary or redundant information 
>>> such as in an individual stored property declaration are not that big a 
>>> deal.  But on balance they add up quickly and have an undesirable impact on 
>>> the overall clarity of code.
>>> 
>>> >
>>> > Daniel Duan
>>> > ___
>>> > 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
>> 
>> 
>> 
>> -- 
>> Pranshu Goyal
>> iOS Developer
>> tlkn
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jaden Geller via swift-evolution]

> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value,
>> Slava brought up some performance problems caused by type inference for
>> stored properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members
>> contemplated requiring types for stored properties in type declarations.
>> I think this idea deserves some more attention. Hence this last minute
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation,
>> there're always the general benefit of making type declartion more
>> explicit and readable (clarity for reader should out-weigh pleasure of
>> the author). Making the language slightly more consistent (we are not
>> inferring types for default parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the
>> language feels more friendly and is, undoubtedly, a beloved feature for
>> many. This would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do
>> y'all think?
> 
> Although it seems like only an implementation-side problem(i.e. "let's just 
> improve implementation"), I see a benefits to require type for stored 
> property *if* it is not obvious what the type is for *reader*. I.e. if we 
> have something like this, I don't think we should require a type:
> struct S {
>  var x = 0
> }

I think there is value in requiring a type annotation there. For example, this 
bug would be avoided: https://twitter.com/benjaminencz/status/851892622213783552

> 
> but I do think it will be better to require a type in such cases :
> 
> struct S{
>  var x = something(SomeType(), 123, "123") // can be generic func
> }
> 
> 
> 
>> 
>> Daniel Duan ___
>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[John McCall via swift-evolution]

> On Apr 11, 2017, at 8:18 PM, Jakub Suder via swift-evolution 
>  wrote:
> 
> I'm honestly having trouble believing that this is being seriously 
> proposed... I always saw type inference as one of the most important 
> advantages of Swift over some older languages, the Swift ebook mentions many 
> times how smart Swift is that it can infer types for you so that you don't 
> have to type too much boilerplate. And here we're talking about removing this 
> feature that was advertised from the beginning as Swift's strong point, in 
> order to make the compilation faster? The compiler speeds will be improved, 
> the syntax will stay with us.
> 
> Yes, specifying the type is often clearer, I do it myself, e.g. "var enabled: 
> Bool = true". But that's my choice, not something I should be forced to do. 
> It's something to put in style guides, not to enforce with the compiler.

To be clear, it's being "seriously proposed" in the sense that someone sent an 
email to a mailing list.

John.

> 
> 
> On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution 
> > wrote:
> I agree with the sentiment of the proposal, it does add value to overall 
> efficiency of swift and make things simpler for the swift team, but as 
> Matthew said a blanket ban will add noise to the code. Also this particular 
> feature is one of those niceties about swift which makes it very welcoming to 
> new adopters.
> 
> If some middle ground can be proposed to this problem then I think we will be 
> making a lot of people happy.
> 
> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution 
> > wrote:
> 
> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
> > > wrote:
> >
> > Hi all,
> >
> > In a discussion about inferring parameter types from default value, Slava 
> > brought up some performance problems caused by type inference for stored 
> > properties in side types:
> >
> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> >  
> > 
> >
> > Towards the end, the post mentioned that some Swift team members 
> > contemplated requiring types for stored properties in type declarations. I 
> > think this idea deserves some more attention. Hence this last minute 
> > idea-floating.
> >
> > In addition to solving a performance headache in implementation, there're 
> > always the general benefit of making type declartion more explicit and 
> > readable (clarity for reader should out-weigh pleasure of the author). 
> > Making the
> > language slightly more consistent (we are not inferring types for default 
> > parameter values in function anyways).
> >
> > The cons for doing this are obvious too: the inference makes the language 
> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
> > would be a source breaking change.
> >
> > Just thought I'd float the idea to gather some quick reaction. What do 
> > y'all think?
> 
> I’m willing to keep an open mind on this topic but I don’t think wholesale 
> banning of inference is the right thing to do.  Here is an example of a case 
> where I do not want to give up inference.  When a property is initialized 
> inline by calling an initializer of a non-generic type (very common) any 
> annotation is strictly redundant.
> 
> struct {
> let foo = Foo()
> }
> 
> Requiring a type annotation here feels very unnecessary and boilerplate-y.  I 
> adds no additional clarity to a reader of the code, only noise.  Noise 
> reduces clarity.  Small amounts of unnecessary or redundant information such 
> as in an individual stored property declaration are not that big a deal.  But 
> on balance they add up quickly and have an undesirable impact on the overall 
> clarity of code.
> 
> >
> > Daniel Duan
> > ___
> > 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 
> 
> 
> 
> 
> -- 
> Pranshu Goyal
> iOS Developer
> tlkn
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jakub Suder via swift-evolution]

I'm honestly having trouble believing that this is being seriously
proposed... I always saw type inference as one of the most important
advantages of Swift over some older languages, the Swift ebook mentions
many times how smart Swift is that it can infer types for you so that you
don't have to type too much boilerplate. And here we're talking about
removing this feature that was advertised from the beginning as Swift's
strong point, in order to make the compilation faster? The compiler speeds
will be improved, the syntax will stay with us.

Yes, specifying the type is often clearer, I do it myself, e.g. "var
enabled: Bool = true". But that's my choice, not something I should be
forced to do. It's something to put in style guides, not to enforce with
the compiler.


On 8 April 2017 at 07:40, Pranshu Goyal via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with the sentiment of the proposal, it does add value to overall
> efficiency of swift and make things simpler for the swift team, but as
> Matthew said a blanket ban will add noise to the code. Also this particular
> feature is one of those niceties about swift which makes it very welcoming
> to new adopters.
>
> If some middle ground can be proposed to this problem then I think we will
> be making a lot of people happy.
>
> On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > Hi all,
>> >
>> > In a discussion about inferring parameter types from default value,
>> Slava brought up some performance problems caused by type inference for
>> stored properties in side types:
>> >
>> > https://lists.swift.org/pipermail/swift-evolution/Week-of-
>> Mon-20170313/033882.html
>> >
>> > Towards the end, the post mentioned that some Swift team members
>> contemplated requiring types for stored properties in type declarations. I
>> think this idea deserves some more attention. Hence this last minute
>> idea-floating.
>> >
>> > In addition to solving a performance headache in implementation,
>> there're always the general benefit of making type declartion more explicit
>> and readable (clarity for reader should out-weigh pleasure of the author).
>> Making the
>> > language slightly more consistent (we are not inferring types for
>> default parameter values in function anyways).
>> >
>> > The cons for doing this are obvious too: the inference makes the
>> language feels more friendly and is, undoubtedly, a beloved feature for
>> many. This would be a source breaking change.
>> >
>> > Just thought I'd float the idea to gather some quick reaction. What do
>> y'all think?
>>
>> I’m willing to keep an open mind on this topic but I don’t think
>> wholesale banning of inference is the right thing to do.  Here is an
>> example of a case where I do not want to give up inference.  When a
>> property is initialized inline by calling an initializer of a non-generic
>> type (very common) any annotation is strictly redundant.
>>
>> struct {
>> let foo = Foo()
>> }
>>
>> Requiring a type annotation here feels very unnecessary and
>> boilerplate-y.  I adds no additional clarity to a reader of the code, only
>> noise.  Noise reduces clarity.  Small amounts of unnecessary or redundant
>> information such as in an individual stored property declaration are not
>> that big a deal.  But on balance they add up quickly and have an
>> undesirable impact on the overall clarity of code.
>>
>> >
>> > Daniel Duan
>> > ___
>> > 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
>>
>
>
>
> --
> *Pranshu Goyal*
> *iOS Developer*
> *tlkn*
>
> ___
> 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] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

We currently pay a dear cost in compilation time for all the features Swift 
brings and this in itself harm productivity quite a bit, the gulf between Swift 
and Objective-C projects compile time wise is massive and right nowt seems like 
we are ignoring it sometimes. Type inference can be a non trivial component of 
that and while it is a wow factor feature initially, it has never been clear as 
a practical big win when code being self documenting and easy to debug and 
maintain is concerned... 

Sent from my iPhone

> On 11 Apr 2017, at 00:26, David Beck via swift-evolution 
>  wrote:
> 
> This seems like something a linter should handle.
> 
> > Hi all,
> > 
> > In a discussion about inferring parameter types from default value, Slava 
> > brought up some performance problems caused by type inference for stored 
> > properties in side types:
> > 
> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> > 
> > Towards the end, the post mentioned that some Swift team members 
> > contemplated requiring types for stored properties in type declarations. I 
> > think this idea deserves some more attention. Hence this last minute 
> > idea-floating.
> > 
> > In addition to solving a performance headache in implementation, there're 
> > always the general benefit of making type declartion more explicit and 
> > readable (clarity for reader should out-weigh pleasure of the author). 
> > Making the
> > language slightly more consistent (we are not inferring types for default 
> > parameter values in function anyways).
> > 
> > The cons for doing this are obvious too: the inference makes the language 
> > feels more friendly and is, undoubtedly, a beloved feature for many. This 
> > would be a source breaking change.
> > 
> > Just thought I'd float the idea to gather some quick reaction. What do 
> > y'all think?
> > 
> > Daniel Duan
> > 
> > 
> >  
> 
> 
> David Beck
> http://davidbeck.co
> http://twitter.com/davbeck
> http://facebook.com/davbeck
> 
> ___
> 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] [Pitch] Remove type-inference for stored property

[David Beck via swift-evolution]

This seems like something a linter should handle.

> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> 
> 
>  


David Beck
http://davidbeck.co
http://twitter.com/davbeck
http://facebook.com/davbeck

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 1:04 PM, Daniel Duan  wrote:
> 
>> 
>> On Apr 10, 2017, at 10:52 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
>>> 
>>> No offense taken. 
>>> 
>>> There's no inherent problem with designing language with available tools in 
>>> mind. After all, what we put in the language is a strict subset of what's 
>>> viable in a compiler. 
>>> 
>>> IMHO Swift should care more about separation of language and tools due to 
>>> its long-term ambition: is it a good language out side of the most typical 
>>> experience? If I edit the source with my favorite editor, on Linux, and/or 
>>> compile with an alternative compiler, can I get a similar experience ?
>>> 
>>> A language that conquers the world shouldn't depend on tools to be awesome.
>> 
>> I agree with this.  I just don’t think inference depends on tools.  It only 
>> depends on reasonable judgement by authors.  The same can be said for many 
>> features that we don’t want to do without.  Inference just happens to be an 
>> area where tools can help out when 1) a beginner or someone new to Swift is 
>> reading the code or 2) the author left off an annotation where maybe they 
>> should have included one.
> I’d argue that a fix-it suggestion should do. Tools can go above and beyond 
> what the the language defines of course. 

How would the fix-it stay out of the way when the annotation really isn’t 
intended?  

>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
 
 
> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are 
> using tools with certain capability is kind of a bad thing.
 
 I see this sentiment on this list a lot. Where does it come from? Is there 
 any supporting research? What drives it?
 
 (I don’t mean to pick on Daniel - I’m curious about this overall from 
 anyone that has sources. It has become such a prevailing refrain at times 
 that I think it’d be best for everyone if we knew if it was even true!)
 
 l8r
 Sean

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

> On Apr 10, 2017, at 10:52 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
>> 
>> No offense taken. 
>> 
>> There's no inherent problem with designing language with available tools in 
>> mind. After all, what we put in the language is a strict subset of what's 
>> viable in a compiler. 
>> 
>> IMHO Swift should care more about separation of language and tools due to 
>> its long-term ambition: is it a good language out side of the most typical 
>> experience? If I edit the source with my favorite editor, on Linux, and/or 
>> compile with an alternative compiler, can I get a similar experience ?
>> 
>> A language that conquers the world shouldn't depend on tools to be awesome.
> 
> I agree with this.  I just don’t think inference depends on tools.  It only 
> depends on reasonable judgement by authors.  The same can be said for many 
> features that we don’t want to do without.  Inference just happens to be an 
> area where tools can help out when 1) a beginner or someone new to Swift is 
> reading the code or 2) the author left off an annotation where maybe they 
> should have included one.
I’d argue that a fix-it suggestion should do. Tools can go above and beyond 
what the the language defines of course. 
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
>>> 
>>> 
 On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
 
 Using tools isn't a bad thing. Designing language assuming users are using 
 tools with certain capability is kind of a bad thing.
>>> 
>>> I see this sentiment on this list a lot. Where does it come from? Is there 
>>> any supporting research? What drives it?
>>> 
>>> (I don’t mean to pick on Daniel - I’m curious about this overall from 
>>> anyone that has sources. It has become such a prevailing refrain at times 
>>> that I think it’d be best for everyone if we knew if it was even true!)
>>> 
>>> l8r
>>> Sean
>>> 
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 12:48 PM, Daniel Duan  wrote:
> 
> No offense taken. 
> 
> There's no inherent problem with designing language with available tools in 
> mind. After all, what we put in the language is a strict subset of what's 
> viable in a compiler. 
> 
> IMHO Swift should care more about separation of language and tools due to its 
> long-term ambition: is it a good language out side of the most typical 
> experience? If I edit the source with my favorite editor, on Linux, and/or 
> compile with an alternative compiler, can I get a similar experience ?
> 
> A language that conquers the world shouldn't depend on tools to be awesome.

I agree with this.  I just don’t think inference depends on tools.  It only 
depends on reasonable judgement by authors.  The same can be said for many 
features that we don’t want to do without.  Inference just happens to be an 
area where tools can help out when 1) a beginner or someone new to Swift is 
reading the code or 2) the author left off an annotation where maybe they 
should have included one.

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>>> 
>>> Using tools isn't a bad thing. Designing language assuming users are using 
>>> tools with certain capability is kind of a bad thing.
>> 
>> I see this sentiment on this list a lot. Where does it come from? Is there 
>> any supporting research? What drives it?
>> 
>> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
>> that has sources. It has become such a prevailing refrain at times that I 
>> think it’d be best for everyone if we knew if it was even true!)
>> 
>> l8r
>> Sean
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

No offense taken. 

There's no inherent problem with designing language with available tools in 
mind. After all, what we put in the language is a strict subset of what's 
viable in a compiler. 

IMHO Swift should care more about separation of language and tools due to its 
long-term ambition: is it a good language out side of the most typical 
experience? If I edit the source with my favorite editor, on Linux, and/or 
compile with an alternative compiler, can I get a similar experience ?

A language that conquers the world shouldn't depend on tools to be awesome.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 10:22 AM, Sean Heber  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
> 
> I see this sentiment on this list a lot. Where does it come from? Is there 
> any supporting research? What drives it?
> 
> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
> that has sources. It has become such a prevailing refrain at times that I 
> think it’d be best for everyone if we knew if it was even true!)
> 
> l8r
> Sean
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Charlie Monroe via swift-evolution]

> On Apr 10, 2017, at 7:22 PM, Sean Heber via swift-evolution 
>  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
> 
> I see this sentiment on this list a lot. Where does it come from? Is there 
> any supporting research? What drives it?

I personally am one of those people advocating not to design it around an IDE 
for these reasons:

- GitHub (or other SCM)
- support for other OSs (as Swift is designed not just for Mac/iOS)
- non-Xcode IDEs. Believe it or not, from time to time I reach for other apps, 
such as CodeRunner.


> 
> (I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
> that has sources. It has become such a prevailing refrain at times that I 
> think it’d be best for everyone if we knew if it was even true!)
> 
> l8r
> Sean
> 
> ___
> 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] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are using 
> tools with certain capability is kind of a bad thing.

I see this sentiment on this list a lot. Where does it come from? Is there any 
supporting research? What drives it?

(I don’t mean to pick on Daniel - I’m curious about this overall from anyone 
that has sources. It has become such a prevailing refrain at times that I think 
it’d be best for everyone if we knew if it was even true!)

l8r
Sean

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jose Cheyo Jimenez via swift-evolution]

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.

My understanding is that the slowdowns are produced when the inference has to 
take into account generics. If somebody is using lots of generics and 
overloads; I would hope they would know that this can slow down compile times. 
I am not sure how this can be communicated to the user other than showing a 
warning. 


> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> ___
> 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] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

That's kind of my perspective too. Personally I adore this feature. But 
compiling speed is such a severe issue at work that I'm willing to part with 
it. (Not saying other arguments aren't important).

I'm lucky enough to work on a project that is:
1. purely Swift
2. Vigilantly monitored for compilation slow-down from complex expressions
3. Really large (enough that compiling speed is a severe problem).

I think with time more and more ppl will experience the same thing.  

As I noted in the proposal, swiftc has space for speed improvement in this area 
and I believe the implementators will get there. In the mean time inference may 
still pose a theoretic performance upper bound. 

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:51 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
>> 
>> Using tools isn't a bad thing. Designing language assuming users are using 
>> tools with certain capability is kind of a bad thing.
>> 
>> Where tools *can* help is if the tools enhance the language user's 
>> experience, which is why I proposed the inference capabilities be kept for 
>> diagnostics.
>> 
>> I also disagree with the characterization that types in properties is 
>> "clustering up" the code. The value inference provided here is make the 
>> authoring experience better. I can see for obvious default expressions 
>> (string/number literal perhaps) the readability isn't degraded by too much. 
>> But it's not as clear as explicit types for the *reader*.
> 
> I said “cluttering”, not “clustering” (which has a more derogatory 
> implication for many people).  
> 
> In any case, this is an area where there are differing perspectives each with 
> some merit.  I think it’s best to leave it up to each of us what makes the 
> most sense for our code.  IMO, and that of at least some others who have 
> commented, some code is more clear to readers with annotations and some is 
> more clear to readers without annotations.  
> 
> Like I said earlier, I’m willing to keep an open mind on proposals in this 
> area but I don’t support a wholesale ban on inference directly initialized 
> member declarations.  It may not be possible to do something less than a 
> wholesale ban without introducing more confusion than we have today as to 
> when inference is permitted and when it isn’t.  If it isn’t that’s ok with 
> me.  If it is, I’ll consider such a proposal on its merit if one is brought 
> forward.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
>>> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  wrote:
>>> 
>>> 
 On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
 
 I guess I'm using the word "export" loosely. Often times I find myself 
 reading type signatures in my own codebase either because it's written by 
 someone else on my team or by myself long time ago. I think open-source 
 library users have the same problem. Exposure to a particular local 
 variable is less likely.
>>> 
>>> If you’re reading code in a codebase you work on most of the time you’ll be 
>>> reading it using a tool that can give you the annotation using something 
>>> like opt-click in Xcode.  I don’t think it’s worth cluttering up our code 
>>> with annotations that are readily available to most readers.  Most of the 
>>> time annotations introduce noise that reduces clarity.  I don’t think 
>>> relying on tools in the occasional case where the type isn’t obvious to an 
>>> individual reader is a bad thing.
>>> 
 
 Daniel Duan
 Sent from my iPhone
 
>> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  
>> wrote:
>> 
>> 
>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> I’m not questioning the value of type inference in general. Just that 
>> there are practical implications when we want more of them. There’s a 
>> difference in inferencing type declaration properties and local 
>> variables: the former is more likely to be exported and read by others. 
>> These arguments are all in the draft proposal.
> 
> When a declaration is exported outside a module whoever is reading it 
> isn’t reading the source directly.  They are reading documentation or a 
> generated header of some kind.  The annotation can easily be added by 
> tools that produce these.
> 
>> 
>>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>>> 
>>> Well, I’m not really a beginner, but for me personally, the computer is 
>>> here to help me do my work and to do some of the thinking for me. I 
>>> really hate repeating myself when it comes to types - especially if the 
>>> types get wordy (collections, etc). Swift is pretty good about it - but 
>>> these warts stick out. The idea that we should make it *less* good 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:38 AM, Daniel Duan  wrote:
> 
> Using tools isn't a bad thing. Designing language assuming users are using 
> tools with certain capability is kind of a bad thing.
> 
> Where tools *can* help is if the tools enhance the language user's 
> experience, which is why I proposed the inference capabilities be kept for 
> diagnostics.
> 
> I also disagree with the characterization that types in properties is 
> "clustering up" the code. The value inference provided here is make the 
> authoring experience better. I can see for obvious default expressions 
> (string/number literal perhaps) the readability isn't degraded by too much. 
> But it's not as clear as explicit types for the *reader*.

I said “cluttering”, not “clustering” (which has a more derogatory implication 
for many people).  

In any case, this is an area where there are differing perspectives each with 
some merit.  I think it’s best to leave it up to each of us what makes the most 
sense for our code.  IMO, and that of at least some others who have commented, 
some code is more clear to readers with annotations and some is more clear to 
readers without annotations.  

Like I said earlier, I’m willing to keep an open mind on proposals in this area 
but I don’t support a wholesale ban on inference directly initialized member 
declarations.  It may not be possible to do something less than a wholesale ban 
without introducing more confusion than we have today as to when inference is 
permitted and when it isn’t.  If it isn’t that’s ok with me.  If it is, I’ll 
consider such a proposal on its merit if one is brought forward.

> 
> Daniel Duan
> Sent from my iPhone
> 
> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  > wrote:
> 
>> 
>>> On Apr 10, 2017, at 11:22 AM, Daniel Duan >> > wrote:
>>> 
>>> I guess I'm using the word "export" loosely. Often times I find myself 
>>> reading type signatures in my own codebase either because it's written by 
>>> someone else on my team or by myself long time ago. I think open-source 
>>> library users have the same problem. Exposure to a particular local 
>>> variable is less likely.
>> 
>> If you’re reading code in a codebase you work on most of the time you’ll be 
>> reading it using a tool that can give you the annotation using something 
>> like opt-click in Xcode.  I don’t think it’s worth cluttering up our code 
>> with annotations that are readily available to most readers.  Most of the 
>> time annotations introduce noise that reduces clarity.  I don’t think 
>> relying on tools in the occasional case where the type isn’t obvious to an 
>> individual reader is a bad thing.
>> 
>>> 
>>> Daniel Duan
>>> Sent from my iPhone
>>> 
 On Apr 10, 2017, at 9:16 AM, Matthew Johnson > wrote:
 
 
> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
> > wrote:
> 
> I’m not questioning the value of type inference in general. Just that 
> there are practical implications when we want more of them. There’s a 
> difference in inferencing type declaration properties and local 
> variables: the former is more likely to be exported and read by others. 
> These arguments are all in the draft proposal.
 
 When a declaration is exported outside a module whoever is reading it 
 isn’t reading the source directly.  They are reading documentation or a 
 generated header of some kind.  The annotation can easily be added by 
 tools that produce these.
 
> 
>> On Apr 10, 2017, at 9:07 AM, Sean Heber > > wrote:
>> 
>> Well, I’m not really a beginner, but for me personally, the computer is 
>> here to help me do my work and to do some of the thinking for me. I 
>> really hate repeating myself when it comes to types - especially if the 
>> types get wordy (collections, etc). Swift is pretty good about it - but 
>> these warts stick out. The idea that we should make it *less* good at 
>> this really rubs me the wrong way. How many times have you seen lines of 
>> code like this in C++-ish/C#-ish languages:
>> 
>> Foo foo = new Foo();
>> 
>> Every time I see that sort of thing, I cringe a little.
>> 
>> IMO if you wanted to be super opinionated, the language would actually 
>> warn if you did this:
>> 
>> let foo: Foo = Foo()
>> 
>> And offer a fixit to:
>> 
>> let foo = Foo()
>> 
>> With no warning for things like this because you’re obviously doing 
>> something intentional:
>> 
>> let foo: FooSuperclass = Foo()
>> 
>> But I’d settle for no warnings and getting the inference to work in all 
>> contexts. :)
>> 
>> l8r

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

Using tools isn't a bad thing. Designing language assuming users are using 
tools with certain capability is kind of a bad thing.

Where tools *can* help is if the tools enhance the language user's experience, 
which is why I proposed the inference capabilities be kept for diagnostics.

I also disagree with the characterization that types in properties is 
"clustering up" the code. The value inference provided here is make the 
authoring experience better. I can see for obvious default expressions 
(string/number literal perhaps) the readability isn't degraded by too much. But 
it's not as clear as explicit types for the *reader*.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:26 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
>> 
>> I guess I'm using the word "export" loosely. Often times I find myself 
>> reading type signatures in my own codebase either because it's written by 
>> someone else on my team or by myself long time ago. I think open-source 
>> library users have the same problem. Exposure to a particular local variable 
>> is less likely.
> 
> If you’re reading code in a codebase you work on most of the time you’ll be 
> reading it using a tool that can give you the annotation using something like 
> opt-click in Xcode.  I don’t think it’s worth cluttering up our code with 
> annotations that are readily available to most readers.  Most of the time 
> annotations introduce noise that reduces clarity.  I don’t think relying on 
> tools in the occasional case where the type isn’t obvious to an individual 
> reader is a bad thing.
> 
>> 
>> Daniel Duan
>> Sent from my iPhone
>> 
 On Apr 10, 2017, at 9:16 AM, Matthew Johnson  
 wrote:
 
 
 On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
  wrote:
 
 I’m not questioning the value of type inference in general. Just that 
 there are practical implications when we want more of them. There’s a 
 difference in inferencing type declaration properties and local variables: 
 the former is more likely to be exported and read by others. These 
 arguments are all in the draft proposal.
>>> 
>>> When a declaration is exported outside a module whoever is reading it isn’t 
>>> reading the source directly.  They are reading documentation or a generated 
>>> header of some kind.  The annotation can easily be added by tools that 
>>> produce these.
>>> 
 
> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
> 
> Well, I’m not really a beginner, but for me personally, the computer is 
> here to help me do my work and to do some of the thinking for me. I 
> really hate repeating myself when it comes to types - especially if the 
> types get wordy (collections, etc). Swift is pretty good about it - but 
> these warts stick out. The idea that we should make it *less* good at 
> this really rubs me the wrong way. How many times have you seen lines of 
> code like this in C++-ish/C#-ish languages:
> 
> Foo foo = new Foo();
> 
> Every time I see that sort of thing, I cringe a little.
> 
> IMO if you wanted to be super opinionated, the language would actually 
> warn if you did this:
> 
> let foo: Foo = Foo()
> 
> And offer a fixit to:
> 
> let foo = Foo()
> 
> With no warning for things like this because you’re obviously doing 
> something intentional:
> 
> let foo: FooSuperclass = Foo()
> 
> But I’d settle for no warnings and getting the inference to work in all 
> contexts. :)
> 
> l8r
> Sean
> 
> 
>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>> 
>> It is helpful in the sense that it tells us what’s really inconsistent: 
>> beginner’s have to learn when inference is available when declaring 
>> their types. That’s story is sketchy.
>>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>>> 
>>> This is not really a helpful comment, but: I kinda wish they did.
>>> 
>>> l8r
>>> Sean
>>> 
 On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Neither of these works btw.
 
 func bar(myString = “hello”)
 class Baz {
 let myString = { return “hello” }()
 }
 
> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How 
> do you explain a new comer that type inference work in some case, but 
> not in other cases, while in both the compiler is completely capable 
> to define the type.
> 
> Why 
> 
> let myString = "hello" 
> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:22 AM, Daniel Duan  wrote:
> 
> I guess I'm using the word "export" loosely. Often times I find myself 
> reading type signatures in my own codebase either because it's written by 
> someone else on my team or by myself long time ago. I think open-source 
> library users have the same problem. Exposure to a particular local variable 
> is less likely.

If you’re reading code in a codebase you work on most of the time you’ll be 
reading it using a tool that can give you the annotation using something like 
opt-click in Xcode.  I don’t think it’s worth cluttering up our code with 
annotations that are readily available to most readers.  Most of the time 
annotations introduce noise that reduces clarity.  I don’t think relying on 
tools in the occasional case where the type isn’t obvious to an individual 
reader is a bad thing.

> 
> Daniel Duan
> Sent from my iPhone
> 
>> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  wrote:
>> 
>> 
>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> I’m not questioning the value of type inference in general. Just that there 
>>> are practical implications when we want more of them. There’s a difference 
>>> in inferencing type declaration properties and local variables: the former 
>>> is more likely to be exported and read by others. These arguments are all 
>>> in the draft proposal.
>> 
>> When a declaration is exported outside a module whoever is reading it isn’t 
>> reading the source directly.  They are reading documentation or a generated 
>> header of some kind.  The annotation can easily be added by tools that 
>> produce these.
>> 
>>> 
 On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
 
 Well, I’m not really a beginner, but for me personally, the computer is 
 here to help me do my work and to do some of the thinking for me. I really 
 hate repeating myself when it comes to types - especially if the types get 
 wordy (collections, etc). Swift is pretty good about it - but these warts 
 stick out. The idea that we should make it *less* good at this really rubs 
 me the wrong way. How many times have you seen lines of code like this in 
 C++-ish/C#-ish languages:
 
 Foo foo = new Foo();
 
 Every time I see that sort of thing, I cringe a little.
 
 IMO if you wanted to be super opinionated, the language would actually 
 warn if you did this:
 
 let foo: Foo = Foo()
 
 And offer a fixit to:
 
 let foo = Foo()
 
 With no warning for things like this because you’re obviously doing 
 something intentional:
 
 let foo: FooSuperclass = Foo()
 
 But I’d settle for no warnings and getting the inference to work in all 
 contexts. :)
 
 l8r
 Sean
 
 
> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
> 
> It is helpful in the sense that it tells us what’s really inconsistent: 
> beginner’s have to learn when inference is available when declaring their 
> types. That’s story is sketchy.
>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>> 
>> This is not really a helpful comment, but: I kinda wish they did.
>> 
>> l8r
>> Sean
>> 
>>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Neither of these works btw.
>>> 
>>> func bar(myString = “hello”)
>>> class Baz {
>>> let myString = { return “hello” }()
>>> }
>>> 
 On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
 
 I’m full -1 on this one. It will make the language inconsistent. How 
 do you explain a new comer that type inference work in some case, but 
 not in other cases, while in both the compiler is completely capable 
 to define the type.
 
 Why 
 
 let myString = "hello" 
 
 would be accepted but not 
 
 class Foo {
   let myString = "hello" 
 }
 
 
 
> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>  a écrit :
> 
> I’m still not sure whether *I* want this. But here’s a proposal 
> anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, 
>> Slava brought up some performance problems caused by type inference 
>> for stored properties in side types:
>> 
>> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

I guess I'm using the word "export" loosely. Often times I find myself reading 
type signatures in my own codebase either because it's written by someone else 
on my team or by myself long time ago. I think open-source library users have 
the same problem. Exposure to a particular local variable is less likely.

Daniel Duan
Sent from my iPhone

> On Apr 10, 2017, at 9:16 AM, Matthew Johnson  wrote:
> 
> 
>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> I’m not questioning the value of type inference in general. Just that there 
>> are practical implications when we want more of them. There’s a difference 
>> in inferencing type declaration properties and local variables: the former 
>> is more likely to be exported and read by others. These arguments are all in 
>> the draft proposal.
> 
> When a declaration is exported outside a module whoever is reading it isn’t 
> reading the source directly.  They are reading documentation or a generated 
> header of some kind.  The annotation can easily be added by tools that 
> produce these.
> 
>> 
>>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>>> 
>>> Well, I’m not really a beginner, but for me personally, the computer is 
>>> here to help me do my work and to do some of the thinking for me. I really 
>>> hate repeating myself when it comes to types - especially if the types get 
>>> wordy (collections, etc). Swift is pretty good about it - but these warts 
>>> stick out. The idea that we should make it *less* good at this really rubs 
>>> me the wrong way. How many times have you seen lines of code like this in 
>>> C++-ish/C#-ish languages:
>>> 
>>> Foo foo = new Foo();
>>> 
>>> Every time I see that sort of thing, I cringe a little.
>>> 
>>> IMO if you wanted to be super opinionated, the language would actually warn 
>>> if you did this:
>>> 
>>> let foo: Foo = Foo()
>>> 
>>> And offer a fixit to:
>>> 
>>> let foo = Foo()
>>> 
>>> With no warning for things like this because you’re obviously doing 
>>> something intentional:
>>> 
>>> let foo: FooSuperclass = Foo()
>>> 
>>> But I’d settle for no warnings and getting the inference to work in all 
>>> contexts. :)
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
 On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
 
 It is helpful in the sense that it tells us what’s really inconsistent: 
 beginner’s have to learn when inference is available when declaring their 
 types. That’s story is sketchy.
> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
> 
> This is not really a helpful comment, but: I kinda wish they did.
> 
> l8r
> Sean
> 
>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Neither of these works btw.
>> 
>> func bar(myString = “hello”)
>> class Baz {
>> let myString = { return “hello” }()
>> }
>> 
>>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>>> 
>>> I’m full -1 on this one. It will make the language inconsistent. How do 
>>> you explain a new comer that type inference work in some case, but not 
>>> in other cases, while in both the compiler is completely capable to 
>>> define the type.
>>> 
>>> Why 
>>> 
>>> let myString = "hello" 
>>> 
>>> would be accepted but not 
>>> 
>>> class Foo {
>>>let myString = "hello" 
>>> }
>>> 
>>> 
>>> 
 Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
  a écrit :
 
 I’m still not sure whether *I* want this. But here’s a proposal 
 anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
 
> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, 
> Slava brought up some performance problems caused by type inference 
> for stored properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members 
> contemplated requiring types for stored properties in type 
> declarations. I think this idea deserves some more attention. Hence 
> this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, 
> there're always the general benefit of making type declartion more 
> explicit and readable (clarity for reader should out-weigh pleasure 
> of the author). Making the
> language slightly more consistent (we are not inferring types for 
> default 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> I’m not questioning the value of type inference in general. Just that there 
> are practical implications when we want more of them. There’s a difference in 
> inferencing type declaration properties and local variables: the former is 
> more likely to be exported and read by others. These arguments are all in the 
> draft proposal.

When a declaration is exported outside a module whoever is reading it isn’t 
reading the source directly.  They are reading documentation or a generated 
header of some kind.  The annotation can easily be added by tools that produce 
these.

> 
>> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
>> 
>> Well, I’m not really a beginner, but for me personally, the computer is here 
>> to help me do my work and to do some of the thinking for me. I really hate 
>> repeating myself when it comes to types - especially if the types get wordy 
>> (collections, etc). Swift is pretty good about it - but these warts stick 
>> out. The idea that we should make it *less* good at this really rubs me the 
>> wrong way. How many times have you seen lines of code like this in 
>> C++-ish/C#-ish languages:
>> 
>> Foo foo = new Foo();
>> 
>> Every time I see that sort of thing, I cringe a little.
>> 
>> IMO if you wanted to be super opinionated, the language would actually warn 
>> if you did this:
>> 
>> let foo: Foo = Foo()
>> 
>> And offer a fixit to:
>> 
>> let foo = Foo()
>> 
>> With no warning for things like this because you’re obviously doing 
>> something intentional:
>> 
>> let foo: FooSuperclass = Foo()
>> 
>> But I’d settle for no warnings and getting the inference to work in all 
>> contexts. :)
>> 
>> l8r
>> Sean
>> 
>> 
>>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>>> 
>>> It is helpful in the sense that it tells us what’s really inconsistent: 
>>> beginner’s have to learn when inference is available when declaring their 
>>> types. That’s story is sketchy.
 On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
 
 This is not really a helpful comment, but: I kinda wish they did.
 
 l8r
 Sean
 
> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Neither of these works btw.
> 
> func bar(myString = “hello”)
> class Baz {
> let myString = { return “hello” }()
> }
> 
>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>> 
>> I’m full -1 on this one. It will make the language inconsistent. How do 
>> you explain a new comer that type inference work in some case, but not 
>> in other cases, while in both the compiler is completely capable to 
>> define the type.
>> 
>> Why 
>> 
>> let myString = "hello" 
>> 
>> would be accepted but not 
>> 
>> class Foo {
>>  let myString = "hello" 
>> }
>> 
>> 
>> 
>>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>>  a écrit :
>>> 
>>> I’m still not sure whether *I* want this. But here’s a proposal 
>>> anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Hi all,
 
 In a discussion about inferring parameter types from default value, 
 Slava brought up some performance problems caused by type inference 
 for stored properties in side types:
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 
 Towards the end, the post mentioned that some Swift team members 
 contemplated requiring types for stored properties in type 
 declarations. I think this idea deserves some more attention. Hence 
 this last minute idea-floating.
 
 In addition to solving a performance headache in implementation, 
 there're always the general benefit of making type declartion more 
 explicit and readable (clarity for reader should out-weigh pleasure of 
 the author). Making the
 language slightly more consistent (we are not inferring types for 
 default parameter values in function anyways).
 
 The cons for doing this are obvious too: the inference makes the 
 language feels more friendly and is, undoubtedly, a beloved feature 
 for many. This would be a source breaking change.
 
 Just thought I'd float the idea to gather some quick reaction. What do 
 y'all think?
 
 Daniel Duan
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 

[swift-evolution] [Pitch] Remove type-inference for stored property

[Seán Labastille via swift-evolution]

Off the top of my head I’m not sure if there is a precedent for such a drastic 
change in behaviour between playgrounds and non-playground compilation.
However, allowing type inference in playgrounds while disallowing this 
otherwise could maintain the benefits for educational and experimental 
scenarios while still eliminating the performance and clarity penalties in 
production (compiled) source files.

> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

I’m not questioning the value of type inference in general. Just that there are 
practical implications when we want more of them. There’s a difference in 
inferencing type declaration properties and local variables: the former is more 
likely to be exported and read by others. These arguments are all in the draft 
proposal.

> On Apr 10, 2017, at 9:07 AM, Sean Heber  wrote:
> 
> Well, I’m not really a beginner, but for me personally, the computer is here 
> to help me do my work and to do some of the thinking for me. I really hate 
> repeating myself when it comes to types - especially if the types get wordy 
> (collections, etc). Swift is pretty good about it - but these warts stick 
> out. The idea that we should make it *less* good at this really rubs me the 
> wrong way. How many times have you seen lines of code like this in 
> C++-ish/C#-ish languages:
> 
> Foo foo = new Foo();
> 
> Every time I see that sort of thing, I cringe a little.
> 
> IMO if you wanted to be super opinionated, the language would actually warn 
> if you did this:
> 
> let foo: Foo = Foo()
> 
> And offer a fixit to:
> 
> let foo = Foo()
> 
> With no warning for things like this because you’re obviously doing something 
> intentional:
> 
> let foo: FooSuperclass = Foo()
> 
> But I’d settle for no warnings and getting the inference to work in all 
> contexts. :)
> 
> l8r
> Sean
> 
> 
>> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
>> 
>> It is helpful in the sense that it tells us what’s really inconsistent: 
>> beginner’s have to learn when inference is available when declaring their 
>> types. That’s story is sketchy.
>>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>>> 
>>> This is not really a helpful comment, but: I kinda wish they did.
>>> 
>>> l8r
>>> Sean
>>> 
 On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Neither of these works btw.
 
 func bar(myString = “hello”)
 class Baz {
 let myString = { return “hello” }()
 }
 
> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How do 
> you explain a new comer that type inference work in some case, but not in 
> other cases, while in both the compiler is completely capable to define 
> the type.
> 
> Why 
> 
> let myString = "hello" 
> 
> would be accepted but not 
> 
> class Foo {
>   let myString = "hello" 
> }
> 
> 
> 
>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>  a écrit :
>> 
>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>> 
>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> In a discussion about inferring parameter types from default value, 
>>> Slava brought up some performance problems caused by type inference for 
>>> stored properties in side types:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>> 
>>> Towards the end, the post mentioned that some Swift team members 
>>> contemplated requiring types for stored properties in type 
>>> declarations. I think this idea deserves some more attention. Hence 
>>> this last minute idea-floating.
>>> 
>>> In addition to solving a performance headache in implementation, 
>>> there're always the general benefit of making type declartion more 
>>> explicit and readable (clarity for reader should out-weigh pleasure of 
>>> the author). Making the
>>> language slightly more consistent (we are not inferring types for 
>>> default parameter values in function anyways).
>>> 
>>> The cons for doing this are obvious too: the inference makes the 
>>> language feels more friendly and is, undoubtedly, a beloved feature for 
>>> many. This would be a source breaking change.
>>> 
>>> Just thought I'd float the idea to gather some quick reaction. What do 
>>> y'all think?
>>> 
>>> Daniel Duan
>>> ___
>>> 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
>>> 
>> 
> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

Well, I’m not really a beginner, but for me personally, the computer is here to 
help me do my work and to do some of the thinking for me. I really hate 
repeating myself when it comes to types - especially if the types get wordy 
(collections, etc). Swift is pretty good about it - but these warts stick out. 
The idea that we should make it *less* good at this really rubs me the wrong 
way. How many times have you seen lines of code like this in C++-ish/C#-ish 
languages:

Foo foo = new Foo();

Every time I see that sort of thing, I cringe a little.

IMO if you wanted to be super opinionated, the language would actually warn if 
you did this:

let foo: Foo = Foo()

And offer a fixit to:

let foo = Foo()

With no warning for things like this because you’re obviously doing something 
intentional:

let foo: FooSuperclass = Foo()

But I’d settle for no warnings and getting the inference to work in all 
contexts. :)

l8r
Sean


> On Apr 10, 2017, at 10:58 AM, Daniel Duan  wrote:
> 
> It is helpful in the sense that it tells us what’s really inconsistent: 
> beginner’s have to learn when inference is available when declaring their 
> types. That’s story is sketchy.
>> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
>> 
>> This is not really a helpful comment, but: I kinda wish they did.
>> 
>> l8r
>> Sean
>> 
>>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> Neither of these works btw.
>>> 
>>> func bar(myString = “hello”)
>>> class Baz {
>>> let myString = { return “hello” }()
>>> }
>>> 
 On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
 
 I’m full -1 on this one. It will make the language inconsistent. How do 
 you explain a new comer that type inference work in some case, but not in 
 other cases, while in both the compiler is completely capable to define 
 the type.
 
 Why 
 
 let myString = "hello" 
 
 would be accepted but not 
 
 class Foo {
let myString = "hello" 
 }
 
 
 
> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>  a écrit :
> 
> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, 
>> Slava brought up some performance problems caused by type inference for 
>> stored properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. 
>> I think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, 
>> there're always the general benefit of making type declartion more 
>> explicit and readable (clarity for reader should out-weigh pleasure of 
>> the author). Making the
>> language slightly more consistent (we are not inferring types for 
>> default parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the 
>> language feels more friendly and is, undoubtedly, a beloved feature for 
>> many. This would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do 
>> y'all think?
>> 
>> Daniel Duan
>> ___
>> 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
>> 
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

It is helpful in the sense that it tells us what’s really inconsistent: 
beginner’s have to learn when inference is available when declaring their 
types. That’s story is sketchy.
> On Apr 10, 2017, at 8:55 AM, Sean Heber  wrote:
> 
> This is not really a helpful comment, but: I kinda wish they did.
> 
> l8r
> Sean
> 
>> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Neither of these works btw.
>> 
>> func bar(myString = “hello”)
>> class Baz {
>>  let myString = { return “hello” }()
>> }
>> 
>>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>>> 
>>> I’m full -1 on this one. It will make the language inconsistent. How do you 
>>> explain a new comer that type inference work in some case, but not in other 
>>> cases, while in both the compiler is completely capable to define the type.
>>> 
>>> Why 
>>> 
>>> let myString = "hello" 
>>> 
>>> would be accepted but not 
>>> 
>>> class Foo {
>>> let myString = "hello" 
>>> }
>>> 
>>> 
>>> 
 Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
  a écrit :
 
 I’m still not sure whether *I* want this. But here’s a proposal anyways: 
 https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
 
> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members 
> contemplated requiring types for stored properties in type declarations. 
> I think this idea deserves some more attention. Hence this last minute 
> idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). 
> Making the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do 
> y'all think?
> 
> Daniel Duan
> ___
> 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
> 

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Sean Heber via swift-evolution]

This is not really a helpful comment, but: I kinda wish they did.

l8r
Sean

> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Neither of these works btw.
> 
> func bar(myString = “hello”)
> class Baz {
>   let myString = { return “hello” }()
> }
> 
>> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
>> 
>> I’m full -1 on this one. It will make the language inconsistent. How do you 
>> explain a new comer that type inference work in some case, but not in other 
>> cases, while in both the compiler is completely capable to define the type.
>> 
>> Why 
>> 
>> let myString = "hello" 
>> 
>> would be accepted but not 
>> 
>> class Foo {
>>  let myString = "hello" 
>> }
>> 
>> 
>> 
>>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>>>  a écrit :
>>> 
>>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
>>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
  wrote:
 
 Hi all,
 
 In a discussion about inferring parameter types from default value, Slava 
 brought up some performance problems caused by type inference for stored 
 properties in side types:
 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
 
 Towards the end, the post mentioned that some Swift team members 
 contemplated requiring types for stored properties in type declarations. I 
 think this idea deserves some more attention. Hence this last minute 
 idea-floating.
 
 In addition to solving a performance headache in implementation, there're 
 always the general benefit of making type declartion more explicit and 
 readable (clarity for reader should out-weigh pleasure of the author). 
 Making the
 language slightly more consistent (we are not inferring types for default 
 parameter values in function anyways).
 
 The cons for doing this are obvious too: the inference makes the language 
 feels more friendly and is, undoubtedly, a beloved feature for many. This 
 would be a source breaking change.
 
 Just thought I'd float the idea to gather some quick reaction. What do 
 y'all think?
 
 Daniel Duan
 ___
 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

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

Neither of these works btw.

func bar(myString = “hello”)
class Baz {
  let myString = { return “hello” }()
}

> On Apr 9, 2017, at 11:26 PM, Jean-Daniel  wrote:
> 
> I’m full -1 on this one. It will make the language inconsistent. How do you 
> explain a new comer that type inference work in some case, but not in other 
> cases, while in both the compiler is completely capable to define the type.
> 
> Why 
> 
> let myString = "hello" 
> 
> would be accepted but not 
> 
> class Foo {
>   let myString = "hello" 
> }
> 
> 
> 
>> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>> > a écrit :
>> 
>> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
>> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 
>> 
>> 
>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
>>> Hi all,
>>> 
>>> In a discussion about inferring parameter types from default value, Slava 
>>> brought up some performance problems caused by type inference for stored 
>>> properties in side types:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>>  
>>> 
>>> 
>>> Towards the end, the post mentioned that some Swift team members 
>>> contemplated requiring types for stored properties in type declarations. I 
>>> think this idea deserves some more attention. Hence this last minute 
>>> idea-floating.
>>> 
>>> In addition to solving a performance headache in implementation, there're 
>>> always the general benefit of making type declartion more explicit and 
>>> readable (clarity for reader should out-weigh pleasure of the author). 
>>> Making the
>>> language slightly more consistent (we are not inferring types for default 
>>> parameter values in function anyways).
>>> 
>>> The cons for doing this are obvious too: the inference makes the language 
>>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> would be a source breaking change.
>>> 
>>> Just thought I'd float the idea to gather some quick reaction. What do 
>>> y'all think?
>>> 
>>> Daniel Duan
>>> ___
>>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jean-Daniel via swift-evolution]

I’m full -1 on this one. It will make the language inconsistent. How do you 
explain a new comer that type inference work in some case, but not in other 
cases, while in both the compiler is completely capable to define the type.

Why 

let myString = "hello" 

would be accepted but not 

class Foo {
let myString = "hello" 
}



> Le 10 avr. 2017 à 04:05, Daniel Duan via swift-evolution 
>  a écrit :
> 
> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 
> 
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, Slava 
>> brought up some performance problems caused by type inference for stored 
>> properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>  
>> 
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. I 
>> think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, there're 
>> always the general benefit of making type declartion more explicit and 
>> readable (clarity for reader should out-weigh pleasure of the author). 
>> Making the
>> language slightly more consistent (we are not inferring types for default 
>> parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the language 
>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>> would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do y'all 
>> think?
>> 
>> Daniel Duan
>> ___
>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Ricardo Parada via swift-evolution]

Type inference is one of my favorite features of Seift. I don't think anything 
would make me change my mind. I read the proposal and couldn't quite figure out 
why such a request. 

I still have to read the links that explain why though. 

Regards


> On Apr 9, 2017, at 10:05 PM, Daniel Duan via swift-evolution 
>  wrote:
> 
> I’m still not sure whether *I* want this. But here’s a proposal anyways: 
> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, Slava 
>> brought up some performance problems caused by type inference for stored 
>> properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. I 
>> think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, there're 
>> always the general benefit of making type declartion more explicit and 
>> readable (clarity for reader should out-weigh pleasure of the author). 
>> Making the
>> language slightly more consistent (we are not inferring types for default 
>> parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the language 
>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>> would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do y'all 
>> think?
>> 
>> Daniel Duan
>> ___
>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

I’m still not sure whether *I* want this. But here’s a proposal anyways: 
https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 


> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?
> 
> Daniel Duan
> ___
> 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] [Pitch] Remove type-inference for stored property

[Kevin Nattinger via swift-evolution]

I am 110% AGAINST this change.  Having complex expressions as a stored property 
initializer is bad practice anyway, and having the type prefixed in that case 
provides at best marginal improvement in clarity and doesn’t fix the underlying 
problem.  

Type inference on simple expressions allows you to put the emphasis on the 
value, rather than the type—e.g. `let defaultTimeout = 5 as TimeInterval` is 
way easier to read and understand than `let defaultTimeout: TimeInterval = 5`; 
and it only gets worse if you declare something with a long class name—`let 
fooBarBazzerciser: MyReallyReallyLongType = MyReallyReallyLongType(argumentOne: 
1, argumentTwo: 2)`—you might even have to scroll horizontally just to see what 
the arguments are! Clarity lost, none gained.


> On Apr 9, 2017, at 3:04 PM, T.J. Usiyan via swift-evolution 
>  wrote:
> 
> I would be alright with this change. The slight inconvenience, even in 
> teaching, would be worth it, in my opinion. It is easier for developers to 
> reason about the types intended when they are made explicit.
> 
> On Sun, Apr 9, 2017 at 6:01 PM, Jon Shier via swift-evolution 
> > wrote:
>   I generally dislike any language change desired because it makes the 
> compiler implementation easier. We saw a few such changes for Swift 3 and all 
> of them were net negatives for the actual users of the language (to a minor 
> extent for most, to be fair).  I would hope that, as the compiler matures, 
> these types of inference performance issues will become less of a problem. 
> Removing a rather nice language feature, especially one that plays such a big 
> role in the “feel” of the language, for short term gain seems rather 
> shortsighted to me.
> 
> 
> 
> Jon Shier
> 
> 
> 
>> On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution 
>> > wrote:
>> 
>> If inference only works in simple cases, I think it would seem like it works 
>> unpredictability to anyone unfamiliar with the implementation details.
>> 
>> I image the question of "why do I have to declare a type here, but not in 
>> this case?" coming up.
>> 
>> Declaring types is one of the first things you have to learn anyway. Just 
>> declaring a function already requires some understanding of types. 
>> Properties are not much different IMO.
>> 
>> On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
 On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
 > wrote:
 
 The cons for doing this are obvious too: the inference makes the language 
 feels more friendly and is, undoubtedly, a beloved feature for many. This 
 would be a source breaking change.
>>> 
>>> 
>>> Beyond just being more friendly, I think it could be considered a teaching 
>>> issue. A great way to introduce beginners to custom types would be 
>>> something like:
>>> 
>>> struct Point {
>>> var x = 0.0
>>> var y = 0.0
>>> }
>>> 
>>> Or:
>>> 
>>> struct Person {
>>> var name = ""
>>> var age = 18
>>> }
>>> 
>>> If you have to explicitly specify types for the properties, that's another 
>>> thing you need to introduce to people before you can do this.
>>> 
>>> On the other hand, a very limited form of inference might be fine here. 
>>> Imagine if we did a sort of limited, single-pass, top-down inference which 
>>> only understood a few things (literals, tuple syntax, initializer calls), 
>>> stopped once it had seen enough to infer a complete type, and rejected an 
>>> expression if it encountered something it didn't understand before 
>>> finishing. That would probably cover most simple cases, and it would 
>>> probably only allow expressions whose types were obvious enough that we 
>>> could use it for arguments, too. (But of course it would mean more code in 
>>> the compiler, so it might not be worth it.)
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>>> ___
>>> 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 
> 

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Jon Shier via swift-evolution]

I generally dislike any language change desired because it makes the 
compiler implementation easier. We saw a few such changes for Swift 3 and all 
of them were net negatives for the actual users of the language (to a minor 
extent for most, to be fair).  I would hope that, as the compiler matures, 
these types of inference performance issues will become less of a problem. 
Removing a rather nice language feature, especially one that plays such a big 
role in the “feel” of the language, for short term gain seems rather 
shortsighted to me.



Jon Shier


> On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution 
>  wrote:
> 
> If inference only works in simple cases, I think it would seem like it works 
> unpredictability to anyone unfamiliar with the implementation details.
> 
> I image the question of "why do I have to declare a type here, but not in 
> this case?" coming up.
> 
> Declaring types is one of the first things you have to learn anyway. Just 
> declaring a function already requires some understanding of types. Properties 
> are not much different IMO.
> 
> On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution 
> > wrote:
> 
>>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>> > wrote:
>>> 
>>> The cons for doing this are obvious too: the inference makes the language 
>>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> would be a source breaking change.
>> 
>> 
>> Beyond just being more friendly, I think it could be considered a teaching 
>> issue. A great way to introduce beginners to custom types would be something 
>> like:
>> 
>>  struct Point {
>>  var x = 0.0
>>  var y = 0.0
>>  }
>> 
>> Or:
>> 
>>  struct Person {
>>  var name = ""
>>  var age = 18
>>  }
>> 
>> If you have to explicitly specify types for the properties, that's another 
>> thing you need to introduce to people before you can do this.
>> 
>> On the other hand, a very limited form of inference might be fine here. 
>> Imagine if we did a sort of limited, single-pass, top-down inference which 
>> only understood a few things (literals, tuple syntax, initializer calls), 
>> stopped once it had seen enough to infer a complete type, and rejected an 
>> expression if it encountered something it didn't understand before 
>> finishing. That would probably cover most simple cases, and it would 
>> probably only allow expressions whose types were obvious enough that we 
>> could use it for arguments, too. (But of course it would mean more code in 
>> the compiler, so it might not be worth it.)
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Charlie Monroe via swift-evolution]

+1 on removing the inference. I actually always declare the type for stored 
properties as well for better readability...

> On Apr 9, 2017, at 5:28 PM, Lucas Neiva via swift-evolution 
>  wrote:
> 
> (Forgot CC. How's that Discord coming along? )
> 
> On 7 Apr 2017, at 13:07, Lucas Neiva > 
> wrote:
> 
>> +1
>> 
>> I think declaring property types is beneficial to readability.
>> 
>> It seems to me like properties are on the same level as functions, where 
>> types are also not inferred. I see them both as “members”, if you like.
>> 
>> Another thing is that computed properties also require an explicit type, 
>> which sometimes trips me up a bit when mixing computed and normal properties.
>> 
>> On Apr 07, 2017, at 09:21 AM, Daniel Duan via swift-evolution 
>> > wrote:
>> 
>>> Hi all,
>>> 
>>> In a discussion about inferring parameter types from default value, Slava 
>>> brought up some performance problems caused by type inference for stored 
>>> properties in side types:
>>> 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>>>  
>>> 
>>> 
>>> Towards the end, the post mentioned that some Swift team members 
>>> contemplated requiring types for stored properties in type declarations. I 
>>> think this idea deserves some more attention. Hence this last minute 
>>> idea-floating.
>>> 
>>> In addition to solving a performance headache in implementation, there're 
>>> always the general benefit of making type declartion more explicit and 
>>> readable (clarity for reader should out-weigh pleasure of the author). 
>>> Making the
>>> language slightly more consistent (we are not inferring types for default 
>>> parameter values in function anyways).
>>> 
>>> The cons for doing this are obvious too: the inference makes the language 
>>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>>> would be a source breaking change.
>>> 
>>> Just thought I'd float the idea to gather some quick reaction. What do 
>>> y'all think?
>>> 
>>> Daniel Duan
>>> ___
>>> 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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Lucas Neiva via swift-evolution]

(Forgot CC. How's that Discord coming along? )

> On 7 Apr 2017, at 13:07, Lucas Neiva  wrote:
> 
> +1
> 
> I think declaring property types is beneficial to readability.
> 
> It seems to me like properties are on the same level as functions, where 
> types are also not inferred. I see them both as “members”, if you like.
> 
> Another thing is that computed properties also require an explicit type, 
> which sometimes trips me up a bit when mixing computed and normal properties.
> 
>> On Apr 07, 2017, at 09:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
> 
>> Hi all,
>> 
>> In a discussion about inferring parameter types from default value, Slava 
>> brought up some performance problems caused by type inference for stored 
>> properties in side types:
>> 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
>> 
>> Towards the end, the post mentioned that some Swift team members 
>> contemplated requiring types for stored properties in type declarations. I 
>> think this idea deserves some more attention. Hence this last minute 
>> idea-floating.
>> 
>> In addition to solving a performance headache in implementation, there're 
>> always the general benefit of making type declartion more explicit and 
>> readable (clarity for reader should out-weigh pleasure of the author). 
>> Making the
>> language slightly more consistent (we are not inferring types for default 
>> parameter values in function anyways).
>> 
>> The cons for doing this are obvious too: the inference makes the language 
>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>> would be a source breaking change.
>> 
>> Just thought I'd float the idea to gather some quick reaction. What do y'all 
>> think?
>> 
>> Daniel Duan
>> ___
>> 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] [Pitch] Remove type-inference for stored property

[Lucas Neiva via swift-evolution]

If inference only works in simple cases, I think it would seem like it works 
unpredictability to anyone unfamiliar with the implementation details.

I image the question of "why do I have to declare a type here, but not in this 
case?" coming up.

Declaring types is one of the first things you have to learn anyway. Just 
declaring a function already requires some understanding of types. Properties 
are not much different IMO.

> On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> The cons for doing this are obvious too: the inference makes the language 
>> feels more friendly and is, undoubtedly, a beloved feature for many. This 
>> would be a source breaking change.
> 
> 
> Beyond just being more friendly, I think it could be considered a teaching 
> issue. A great way to introduce beginners to custom types would be something 
> like:
> 
>   struct Point {
>   var x = 0.0
>   var y = 0.0
>   }
> 
> Or:
> 
>   struct Person {
>   var name = ""
>   var age = 18
>   }
> 
> If you have to explicitly specify types for the properties, that's another 
> thing you need to introduce to people before you can do this.
> 
> On the other hand, a very limited form of inference might be fine here. 
> Imagine if we did a sort of limited, single-pass, top-down inference which 
> only understood a few things (literals, tuple syntax, initializer calls), 
> stopped once it had seen enough to infer a complete type, and rejected an 
> expression if it encountered something it didn't understand before finishing. 
> That would probably cover most simple cases, and it would probably only allow 
> expressions whose types were obvious enough that we could use it for 
> arguments, too. (But of course it would mean more code in the compiler, so it 
> might not be worth it.)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] [Pitch] Remove type-inference for stored property

[Goffredo Marocchi via swift-evolution]

Type inference sounds nice initially then you face the costs in compilation 
time and reduced ability to debug and reason about the code months after the 
fact... and you start to rethink things (not every programmer keeps 
maintainability over pretty smart haiku code).

Sent from my iPhone

> On 8 Apr 2017, at 07:35, David Sweeris via swift-evolution 
>  wrote:
> 
> 
>> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution 
>>  wrote:
>> 
>> I agree with the sentiment of the proposal, it does add value to overall 
>> efficiency of swift and make things simpler for the swift team, but as 
>> Matthew said a blanket ban will add noise to the code. Also this particular 
>> feature is one of those niceties about swift which makes it very welcoming 
>> to new adopters.
>> 
>> If some middle ground can be proposed to this problem then I think we will 
>> be making a lot of people happy.
> 
> I don't think I'd mind a flag that disables type inference for properties or 
> something. Really, though, this seems like a linter's job to me.
> 
> Maybe the Swift manual should have a chapter about the trade-offs between 
> code that's quick to write, quick to run, and quick to compile?
> 
> - Dave Sweeris
> ___
> 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] [Pitch] Remove type-inference for stored property

[David Sweeris via swift-evolution]

> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution 
>  wrote:
> 
> I agree with the sentiment of the proposal, it does add value to overall 
> efficiency of swift and make things simpler for the swift team, but as 
> Matthew said a blanket ban will add noise to the code. Also this particular 
> feature is one of those niceties about swift which makes it very welcoming to 
> new adopters.
> 
> If some middle ground can be proposed to this problem then I think we will be 
> making a lot of people happy.

I don't think I'd mind a flag that disables type inference for properties or 
something. Really, though, this seems like a linter's job to me.

Maybe the Swift manual should have a chapter about the trade-offs between code 
that's quick to write, quick to run, and quick to compile?

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Brent Royal-Gordon via swift-evolution]

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.


Beyond just being more friendly, I think it could be considered a teaching 
issue. A great way to introduce beginners to custom types would be something 
like:

struct Point {
var x = 0.0
var y = 0.0
}

Or:

struct Person {
var name = ""
var age = 18
}

If you have to explicitly specify types for the properties, that's another 
thing you need to introduce to people before you can do this.

On the other hand, a very limited form of inference might be fine here. Imagine 
if we did a sort of limited, single-pass, top-down inference which only 
understood a few things (literals, tuple syntax, initializer calls), stopped 
once it had seen enough to infer a complete type, and rejected an expression if 
it encountered something it didn't understand before finishing. That would 
probably cover most simple cases, and it would probably only allow expressions 
whose types were obvious enough that we could use it for arguments, too. (But 
of course it would mean more code in the compiler, so it might not be worth it.)

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Pranshu Goyal via swift-evolution]

I agree with the sentiment of the proposal, it does add value to overall
efficiency of swift and make things simpler for the swift team, but as
Matthew said a blanket ban will add noise to the code. Also this particular
feature is one of those niceties about swift which makes it very welcoming
to new adopters.

If some middle ground can be proposed to this problem then I think we will
be making a lot of people happy.

On 7 April 2017 at 18:31, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> > On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > Hi all,
> >
> > In a discussion about inferring parameter types from default value,
> Slava brought up some performance problems caused by type inference for
> stored properties in side types:
> >
> > https://lists.swift.org/pipermail/swift-evolution/
> Week-of-Mon-20170313/033882.html
> >
> > Towards the end, the post mentioned that some Swift team members
> contemplated requiring types for stored properties in type declarations. I
> think this idea deserves some more attention. Hence this last minute
> idea-floating.
> >
> > In addition to solving a performance headache in implementation,
> there're always the general benefit of making type declartion more explicit
> and readable (clarity for reader should out-weigh pleasure of the author).
> Making the
> > language slightly more consistent (we are not inferring types for
> default parameter values in function anyways).
> >
> > The cons for doing this are obvious too: the inference makes the
> language feels more friendly and is, undoubtedly, a beloved feature for
> many. This would be a source breaking change.
> >
> > Just thought I'd float the idea to gather some quick reaction. What do
> y'all think?
>
> I’m willing to keep an open mind on this topic but I don’t think wholesale
> banning of inference is the right thing to do.  Here is an example of a
> case where I do not want to give up inference.  When a property is
> initialized inline by calling an initializer of a non-generic type (very
> common) any annotation is strictly redundant.
>
> struct {
> let foo = Foo()
> }
>
> Requiring a type annotation here feels very unnecessary and
> boilerplate-y.  I adds no additional clarity to a reader of the code, only
> noise.  Noise reduces clarity.  Small amounts of unnecessary or redundant
> information such as in an individual stored property declaration are not
> that big a deal.  But on balance they add up quickly and have an
> undesirable impact on the overall clarity of code.
>
> >
> > Daniel Duan
> > ___
> > 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
>



-- 
*Pranshu Goyal*
*iOS Developer*
*tlkn*
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

[Matthew Johnson via swift-evolution]

> On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> In a discussion about inferring parameter types from default value, Slava 
> brought up some performance problems caused by type inference for stored 
> properties in side types:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html
> 
> Towards the end, the post mentioned that some Swift team members contemplated 
> requiring types for stored properties in type declarations. I think this idea 
> deserves some more attention. Hence this last minute idea-floating.
> 
> In addition to solving a performance headache in implementation, there're 
> always the general benefit of making type declartion more explicit and 
> readable (clarity for reader should out-weigh pleasure of the author). Making 
> the
> language slightly more consistent (we are not inferring types for default 
> parameter values in function anyways).
> 
> The cons for doing this are obvious too: the inference makes the language 
> feels more friendly and is, undoubtedly, a beloved feature for many. This 
> would be a source breaking change.
> 
> Just thought I'd float the idea to gather some quick reaction. What do y'all 
> think?

I’m willing to keep an open mind on this topic but I don’t think wholesale 
banning of inference is the right thing to do.  Here is an example of a case 
where I do not want to give up inference.  When a property is initialized 
inline by calling an initializer of a non-generic type (very common) any 
annotation is strictly redundant.

struct {
let foo = Foo()
}

Requiring a type annotation here feels very unnecessary and boilerplate-y.  I 
adds no additional clarity to a reader of the code, only noise.  Noise reduces 
clarity.  Small amounts of unnecessary or redundant information such as in an 
individual stored property declaration are not that big a deal.  But on balance 
they add up quickly and have an undesirable impact on the overall clarity of 
code.  

> 
> Daniel Duan
> ___
> 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] [Pitch] Remove type-inference for stored property

[Vladimir.S via swift-evolution]

On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:

Hi all,

In a discussion about inferring parameter types from default value,
Slava brought up some performance problems caused by type inference for
stored properties in side types:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html

 Towards the end, the post mentioned that some Swift team members
contemplated requiring types for stored properties in type declarations.
I think this idea deserves some more attention. Hence this last minute
idea-floating.

In addition to solving a performance headache in implementation,
there're always the general benefit of making type declartion more
explicit and readable (clarity for reader should out-weigh pleasure of
the author). Making the language slightly more consistent (we are not
inferring types for default parameter values in function anyways).

The cons for doing this are obvious too: the inference makes the
language feels more friendly and is, undoubtedly, a beloved feature for
many. This would be a source breaking change.

Just thought I'd float the idea to gather some quick reaction. What do
y'all think?


Although it seems like only an implementation-side problem(i.e. "let's just 
improve implementation"), I see a benefits to require type for stored 
property *if* it is not obvious what the type is for *reader*. I.e. if we 
have something like this, I don't think we should require a type:

struct S {
  var x = 0
}

but I do think it will be better to require a type in such cases :

struct S{
  var x = something(SomeType(), 123, "123") // can be generic func
}





Daniel Duan ___
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] [Pitch] Remove type-inference for stored property

[Daniel Duan via swift-evolution]

Hi all,

In a discussion about inferring parameter types from default value, Slava 
brought up some performance problems caused by type inference for stored 
properties in side types:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html

Towards the end, the post mentioned that some Swift team members contemplated 
requiring types for stored properties in type declarations. I think this idea 
deserves some more attention. Hence this last minute idea-floating.

In addition to solving a performance headache in implementation, there're 
always the general benefit of making type declartion more explicit and readable 
(clarity for reader should out-weigh pleasure of the author). Making the
language slightly more consistent (we are not inferring types for default 
parameter values in function anyways).

The cons for doing this are obvious too: the inference makes the language feels 
more friendly and is, undoubtedly, a beloved feature for many. This would be a 
source breaking change.

Just thought I'd float the idea to gather some quick reaction. What do y'all 
think?

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