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 <matt...@anandabits.com> wrote:
>
>
>> On Apr 10, 2017, at 11:38 AM, Daniel Duan <dan...@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 <matt...@anandabits.com> wrote:
>>>
>>>
>>>> On Apr 10, 2017, at 11:22 AM, Daniel Duan <dan...@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 <matt...@anandabits.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution
>>>>>> <swift-evolution@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 <s...@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 <dan...@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 <s...@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@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 <mail...@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> 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> 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
