> 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
