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*. Daniel Duan Sent from my iPhone > On Apr 10, 2017, at 9:26 AM, Matthew Johnson <[email protected]> wrote: > > >> On Apr 10, 2017, at 11:22 AM, Daniel Duan <[email protected]> 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 <[email protected]> >>>> wrote: >>>> >>>> >>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution >>>> <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>>>>>> <[email protected]> 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 <[email protected]> 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 >>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> <[email protected]> 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 >>>>>>>>>>> [email protected] >>>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> swift-evolution mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
