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

Mon Apr 10 11:38:21 CDT 2017

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 <matthew at anandabits.com> wrote:
> 
> 
>> On Apr 10, 2017, at 11:22 AM, Daniel Duan <daniel at duan.org> 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 <matthew at anandabits.com> wrote:
>>>> 
>>>> 
>>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution <swift-evolution at swift.org> 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 <sean at fifthace.com> 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 <daniel at duan.org> 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 <sean at fifthace.com> 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 <swift-evolution at swift.org> 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 <mailing at 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 at 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 at 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 at swift.org
>>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> swift-evolution mailing list
>>>>>>>>>> swift-evolution at swift.org
>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> swift-evolution mailing list
>>>>>>>> swift-evolution at swift.org
>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170410/36694f40/attachment.html>