[Pitch] Remove type-inference for stored property


(Daniel Duan) #1

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


(Matthew Johnson) #2

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.

···

On Apr 7, 2017, at 2:21 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org> wrote:

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


(Vladimir) #3

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
}

···

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

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


(Brent Royal-Gordon) #4

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.)

···

On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org> 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.

--
Brent Royal-Gordon
Architechies


(Seán Labastille) #5

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


(Daniel Duan) #6

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 <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?

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


(Chéyo Jiménez) #7

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.

···

On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org> wrote:

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


(David Beck) #8

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


(Víctor Pimentel) #9

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.

···

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?

--
Víctor Pimentel

--

INNOVATION IN PERSONAL COMMS

*[image: Imágenes integradas 5]*

*Víctor Pimentel Rodríguez · *Principal iOS Engineer
vpimentel@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


(Pranshu Goyal) #10

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*


(Lucas Neiva) #11

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 <swift-evolution@swift.org> wrote:

On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org> 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


(Ricardo Parada) #12

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 <swift-evolution@swift.org> 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 <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?

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


(Jean-Daniel) #13

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org <mailto: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?

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


(Goffredo Marocchi) #14

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 <swift-evolution@swift.org> 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


(Jaden Geller) #15

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

···

On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote:

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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(David Sweeris) #16

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

···

On Apr 7, 2017, at 22: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.


(Goffredo Marocchi) #17

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 <swift-evolution@swift.org> wrote:

On Apr 7, 2017, at 22: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.

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


(Jon Shier) #18

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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


(Daniel Duan) #19

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 <mailing@xenonium.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto: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?

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

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


(Jakub Suder) #20

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