> On Apr 10, 2017, at 10:52 AM, Matthew Johnson <[email protected]> wrote: > > >> On Apr 10, 2017, at 12:48 PM, Daniel Duan <[email protected]> wrote: >> >> No offense taken. >> >> There's no inherent problem with designing language with available tools in >> mind. After all, what we put in the language is a strict subset of what's >> viable in a compiler. >> >> IMHO Swift should care more about separation of language and tools due to >> its long-term ambition: is it a good language out side of the most typical >> experience? If I edit the source with my favorite editor, on Linux, and/or >> compile with an alternative compiler, can I get a similar experience ? >> >> A language that conquers the world shouldn't depend on tools to be awesome. > > I agree with this. I just don’t think inference depends on tools. It only > depends on reasonable judgement by authors. The same can be said for many > features that we don’t want to do without. Inference just happens to be an > area where tools can help out when 1) a beginner or someone new to Swift is > reading the code or 2) the author left off an annotation where maybe they > should have included one. I’d argue that a fix-it suggestion should do. Tools can go above and beyond what the the language defines of course. > >> >> Daniel Duan >> Sent from my iPhone >> >>> On Apr 10, 2017, at 10:22 AM, Sean Heber <[email protected]> wrote: >>> >>> >>>> On Apr 10, 2017, at 11:38 AM, Daniel Duan <[email protected]> wrote: >>>> >>>> Using tools isn't a bad thing. Designing language assuming users are using >>>> tools with certain capability is kind of a bad thing. >>> >>> I see this sentiment on this list a lot. Where does it come from? Is there >>> any supporting research? What drives it? >>> >>> (I don’t mean to pick on Daniel - I’m curious about this overall from >>> anyone that has sources. It has become such a prevailing refrain at times >>> that I think it’d be best for everyone if we knew if it was even true!) >>> >>> l8r >>> Sean >>> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
