[swift-evolution] Nil coalescing operator precedence

[Vladimir.S]

On 15.06.2016 19:00, Xiaodi Wu wrote:
> On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>     On 15.06.2016 17:19, Sean Heber wrote:
>
>
>             On Jun 15, 2016, at 7:21 AM, Vladimir.S via swift-evolution
>             <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>             wrote:
>
>             I believe we should not take into account any IDE features when
>             discussing the *language*. One will write Swift script code in
>             vim on
>             linux, other will read in web browser on github etc.
>
>
>         Unrelated to anything else in this discussion, I just wanted to respond
>         to this and say that I’m totally opposed to this line of thinking.
>         If we
>         continue to design languages that must accommodate the lowest common
>         denominator in terms of tooling, we’ll never advance anything in
>         meaningful ways. Tooling is super important and it is mostly terrible.
>         It could be so much better. We don’t have much (any?) influence over
>         Xcode via swift-evolution, but if the language evolves in ways where
>         smarter, better, more advanced IDEs are the best way to use it, then
>         Xcode will adapt and if Xcode adapts and proves a better workflow, then
>         other tools will also adapt and everyone in any language on all
>         platforms will eventually benefit from that exploration.
>
>
>     Well, of course I support improvement of tools & IDEs in all the ways
>     that can help developer. But I'm against suggestions to solve some
>     problem *in languge* by introducing some feature in *IDE*(especially in
>     only one IDE - XCode), like the suggestion to solve ambiguity with
>     order of processing in complex expression by *only* showing some hints
>     in XCode.
>     I.e. I'm voting to solve problem in language itself first, and then(or
>     if can't be solved) in IDE.
>
>
> I think the counterpoint to be made here is that if a satisfying solution
> to the problem can be found through better tooling, then arguably the
> problem lies with tooling and not with the language itself.

Yes, probably. But I do believe the language itself is a first class 
citizen, tools are just helpers. You need to have the same coding features 
on any platform/editor/IDE where you write Swift code. You should not be 
able to easily write complex expressions just because of super-smart helper 
in XCode but be without help on Linux platform. Tool can exist for example 
only for XCode but absent for other platform you are coding on also. IMO 
You just can't depend on tools in the question of language features. This 
is my strong opinion.

>
>
>
>
>
>         l8r Sean
>
>
>     _______________________________________________
>     swift-evolution mailing list
>     swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>     https://lists.swift.org/mailman/listinfo/swift-evolution
>
>