I would be alright with this change. The slight inconvenience, even in teaching, would be worth it, in my opinion. It is easier for developers to reason about the types intended when they are made explicit.
On Sun, Apr 9, 2017 at 6:01 PM, Jon Shier via swift-evolution < [email protected]> wrote: > I generally dislike any language change desired because it makes the > compiler implementation easier. We saw a few such changes for Swift 3 and > all of them were net negatives for the actual users of the language (to a > minor extent for most, to be fair). I would hope that, as the compiler > matures, these types of inference performance issues will become less of a > problem. Removing a rather nice language feature, especially one that plays > such a big role in the “feel” of the language, for short term gain seems > rather shortsighted to me. > > > > Jon Shier > > > > On Apr 9, 2017, at 11:23 AM, Lucas Neiva via swift-evolution < > [email protected]> wrote: > > If inference only works in simple cases, I think it would seem like it > works unpredictability to anyone unfamiliar with the implementation details. > > I image the question of "why do I have to declare a type here, but not in > this case?" coming up. > > Declaring types is one of the first things you have to learn anyway. Just > declaring a function already requires some understanding of types. > Properties are not much different IMO. > > On 8 Apr 2017, at 08:34, Brent Royal-Gordon via swift-evolution < > [email protected]> wrote: > > On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution < > [email protected]> wrote: > > 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. > > > Beyond just being more friendly, I think it could be considered a teaching > issue. A great way to introduce beginners to custom types would be > something like: > > struct Point { > var x = 0.0 > var y = 0.0 > } > > Or: > > struct Person { > var name = "" > var age = 18 > } > > If you have to explicitly specify types for the properties, that's another > thing you need to introduce to people before you can do this. > > On the other hand, a very limited form of inference might be fine here. > Imagine if we did a sort of limited, single-pass, top-down inference which > only understood a few things (literals, tuple syntax, initializer calls), > stopped once it had seen enough to infer a complete type, and rejected an > expression if it encountered something it didn't understand before > finishing. That would probably cover most simple cases, and it would > probably only allow expressions whose types were obvious enough that we > could use it for arguments, too. (But of course it would mean more code in > the compiler, so it might not be worth it.) > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
