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:
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?
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:
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:
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:
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:
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.
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:
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?
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:
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?
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:
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?
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:
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.
···
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:
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 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:
>
> The swift-evolution Archives
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.
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.)
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:
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:
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 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 :
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:
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?
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:
>
> [swift-evolution] Infer types of default function parameters
>
> 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
>
>
>
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:
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
}
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
}
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.
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?
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.)
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 :
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:
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 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.
