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.
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
