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

Daniel Duan daniel at duan.org
Mon Apr 10 12:11:16 CDT 2017 

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 <matthew at anandabits.com> wrote:
> 
> 
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan <daniel at duan.org> 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 <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/52b6d691/attachment.html>

More information about the swift-evolution mailing list