[dmd-internals] [Fwd: Re: Is [] mandatory for array operations?]

[Andrei Alexandrescu]

This seems like a sensible policy to me. Walter?

Andrei

-------- Original Message --------
Subject: Re: Is [] mandatory for array operations?
Date: Fri, 07 May 2010 11:11:47 -0400
From: Steven Schveighoffer <schveiguy at yahoo.com>
Organization: Digital Mars
Newsgroups: digitalmars.D
References: <hroge4$2t89$1 at digitalmars.com> 
<hron9c$a15$1 at digitalmars.com> <hrou9e$mlm$1 at digitalmars.com> 
<hrptld$2gi8$2 at digitalmars.com> <hrpvfu$2kfm$1 at digitalmars.com> 
<op.vcb9j8k426stm6 at sandford>

On Fri, 07 May 2010 10:08:22 -0400, Robert Jacques <sandford at jhu.edu>
wrote:

> On Tue, 04 May 2010 16:19:09 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> Walter Bright wrote:
>>> Don wrote:
>>>> Walter Bright wrote:
>>>>> Don wrote:
>>>>>> There are several compiler bugs relating to array operations, and  
>>>>>> almost all relate to this issue. I'd like to fix them, but I need  
>>>>>> to know which way it is supposed to work.
>>>>>
>>>>> The [] should be required. I worry that otherwise there will be  
>>>>> ambiguous cases that will cause trouble.
>>>> Excellent.
>>>  Glad we agree. An example is the C hack where if foo is a function,  
>>> then &foo as well as foo mean the address of the function. This little  
>>> ambiguity, originally meant as a convenience, has caused much grief.
>>
>> In the same vein, probably it's time to bite the bullet and require  
>> @property for parens-less function calls.
>>
>> Andrei
>
> Disagreed. I've really come to enjoy parens-less coding, though I know  
> others don't like it. But today both camps can write in their preferred  
> style and write libraries for each other. Either deciding on an opt-in  
> (@property) or opt-out(@!property) basis seems likely to A) kill the  
> other programming style or B) lead to a bunch of synaptic load on the  
> programmer as they try to remember which style each class uses.

As I've said before, I think a possible compromise to this is to allow
paren-less function calls when the return type is void.  These functions
cannot be misinterpreted as properties.

I won't go over the other points again :)

-Steve