[swift-evolution] Brace syntax
Charles Constant
charles at charlesism.com
Sun Dec 20 13:02:17 CST 2015
Yes, I went out of my way to point out that it *is* contrived, because even
a programmer who uses a newline for the opening brace *elsewhere* in the
same project, isn't going to take up 11 lines to define one variable.
On Sun, Dec 20, 2015 at 7:52 AM, Dennis Lysenko <dennis.s.lysenko at gmail.com>
wrote:
> Contrived example Charles. Apple's tutorials consistently put braces on
> the line of the statement declaration.
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html#//apple_ref/doc/uid/TP40014097-CH9-ID120
>
> On Sun, Dec 20, 2015 at 7:16 AM Charles Constant via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Andrey's post encourages me to veer into the merits of significant
>> whitespace vs braces. This is probably unwise of me, since we're not all
>> going to agree any time soon, but I can't resist pointing out an example:
>>
>> ////////////////////////////////////////////////////////////////////////
>>
>> var foo: Int
>> {
>> get
>> {
>> return _foo
>> }
>> set
>> {
>> _foo = newValue
>> }
>> }
>>
>> ////////////////////////////////////////////////////////////////////////
>>
>> var foo: Int:
>> get:
>> return _foo
>> set:
>> _foo = newValue
>>
>> ////////////////////////////////////////////////////////////////////////
>>
>> It's obvious no programmer is going to be consistent about braces in the
>> first example - it's absurdly verbose. So with braces in Swift, pretty much
>> everything you write carries the overhead of "what inconsistent way will i
>> format the braces for this code?" For me, I'd rather throw out the (largely
>> redundant) noise, and stick with just the content.
>>
>>
>>
>>
>>
>>
>> On Sun, Dec 20, 2015 at 3:59 AM, Andrey Tarantsov via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I don't know many people who have experienced a large variety (8+?) of
>>> programming languages and prefer Python's forced indentation
>>>
>>>
>>> Count me as one. I'd prefer Swift to have Python-style indentation, just
>>> on the grounds of braces being stupid (why would you want to enter the same
>>> scope information *twice*)?
>>>
>>> So +1 from me, although I don't suffer from the braces at all.
>>>
>>> I do want to point out that the amount of code that fits on a screen
>>> *is* fairly important, and you should keep your methods short, so one
>>> less brace per method means a couple more methods per screen.
>>>
>>> This would also free up braces to mean “closure” in 100% of cases, which
>>> is good for consistency.
>>>
>>> But it would introduce it's share of problems for sure, so I don't feel
>>> strongly about this proposal.
>>>
>>> I also admit that braces are generally preferred, for some mysterious
>>> reason that I hope a believer can articulate here. Take Sass, for example;
>>> it has both an indentation-based syntax and a braces-based syntax, and the
>>> latter one seems way more popular.
>>>
>>> A.
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> 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/20151220/27908cea/attachment.html>
More information about the swift-evolution
mailing list