> 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
