[swift-evolution] Nil coalescing operator precedence
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jun 15 11:00:29 CDT 2016
On Wed, Jun 15, 2016 at 10:51 AM, Vladimir.S via swift-evolution <
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> 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.
>
>
>
>> l8r Sean
>>
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160615/bdb3dfeb/attachment.html>
More information about the swift-evolution
mailing list