foo!(bar) ==> foo{bar} ==> foo[bar] (just Brackets)

[Steven Schveighoffer]

"Bruno Medeiros" wrote
> Steven Schveighoffer wrote:
>> This would never happen in my editor (vim), as it does not to semantic 
>> processing.  So I would be forced to get an IDE to work (which I have 
>> tried several now without success).
>>
>> But the point behind all this is, if it takes a compiler (or at least a 
>> semantic processor) to figure out what the code means, what about the 
>> lowly code reviewer?  I don't see how this syntax is so much better than 
>> !() that we should make the language super-difficult for humans to 
>> understand without computer help...
>>
>
> Everything else we do with the language requires computer help: compiling, 
> running, debugging, etc.. I don't see why editing should be any different. 
> Why shouldn't a programming language have in consideration the potential 
> productivity enhancements that tools can bring?

I require a computer to write code already.  I just don't want to have to 
use an IDE to *read* code.

If someone pastes a snippit of code in the NG, for example, I don't want to 
have to fire up an IDE to copy-paste the code, just to understand what it 
means.

This all would be a worthwhile discussion if we didn't already have a really 
good syntax to denote template instantiation which is already implemented, 
is unambiguous, easy to identify, and has no inherent parsing problems. 
Since the bracket syntax does not have some of those features, and it 
functionally adds nothing new, I think the current syntax wins.

>> Yes, but using the wrong type in an AA still gives you an AA.  If 
>> brackets are overloaded for templates, it might give you something 
>> completely different.  You would get confusing mesages like:
>>
>> X[Y] x;
>>
>> x[Y(55)] = new X(3);
>>
>> error: cannot find opIndex for type X[Y]
>>
>> huh??
>>
>> This second level of symptom would be tough to trace back to the root 
>> problem.  This is why it is good to have syntax constructs have a large 
>> hamming distance.
>>
>
> I disagree. I find that most, in not all, of compile errors are very easy 
> to solve, very much more so that the runtime ones. Although in the 
> particular case of DMD, some error messages are somewhat obscure or 
> lacking in info, but that is more of a compiler issue than a language one.

Yes, this would be a case of *not* easy to solve.  We have lots of these 
already, but I don't want to add more.

The point of large hamming distance between syntax is to make it difficult 
to accidentally write compilable code when you didn't mean to.  This is one 
of those cases.

For example, the following doesn't compile:

int i;
for(i = 0; i < 100; i++);
  writeln("%s", i);

Because the compiler is making it difficult for you to screw up.  I'm saying 
that !() has an advantage over the [] syntax because it is more difficult to 
screw up and write something you didn't mean.  The result of which is going 
to be an error not where you expect it, i.e. hard to track down.

-Steve