a modest semicolon thought (was: Re: lazy redux)

Nick Sabalausky a at a.a
Mon Dec 7 10:07:51 PST 2009


"klickverbot" <klickverbot at gmail.com> wrote in message 
news:hfj6eb$kss$1 at digitalmars.com...
> Denis Koroskin wrote:
>> Although I believe it is implementable and worth the trouble, there is a
>> little gain in this feature and that's probably why it is low in the 
>> list.
>> I think that Walter will give a green light if someone implements the
>> feature and provides a complete patch.
>>
>> Any volunteers?
>
> If someone should step forward to implement this: I would really like to 
> be
> able to omit the semicolon inside one-statement delegates/lambdas. It 
> makes
> using them feel much more natural (at least to me) - just look at some 
> Ruby
> code.

I've had an idea for a more expanded version of what you propose:

Many operators tend to fall into one of two categories: Separators vs 
Terminators (separators being ones that are put between two operands, and 
terminators being ones that are put after each operand). Terminators (like 
semicolon) have the advantage of being more consistent, easier to edit, and 
easier to programmatically generate. Separators (like addition) have the 
advantages of being more convenient and less visually-noisy when there are 
just a few operands and often just making more sense for the given task 
(imagine "1+2" being written instead as "1+2+").

Traditionally, every such operator is cemented in stone by the language as 
being either a separator or a terminator. But D has already noticed, at 
least in a small way, that sometimes it's better to leave the separator vs 
terminator choice up to the programmer on a case-by-case basis. 
Specifically, the commas from array literals and [real] enum declarations 
can be used either way. This, of course, is done by making the final one 
optional.

Although I'm one of the people who isn't typically too keen on optional 
semicolons, I've wondered if it may be a good idea to extend this 
"optional-final-operator" concept to semicolons. The primary practical 
reason would be increased convenience and readability for short lambdas (or 
short functions and classes).

And, at least in theory, this could maybe even be extended to all separators 
and terminators, including things like arithmetic and logic. Though that 
wouldn't initially seem to make much sense, the trick would be to just apply 
the operator's identity value (0 for addition, 1 for multiplication, true 
for logical and, false for logical or).  But of course, the downside in 
these cases would be a silent error if you forgot to type the last value.





More information about the Digitalmars-d mailing list