> 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