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 > <swift-evolution@swift.org> 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
