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

[Bruno Medeiros]

Steven Schveighoffer wrote:
> "Bruno Medeiros" wrote
>> Steven Schveighoffer wrote:
>>> Funny, when I hover my mouse over my ssh terminal into the Linux box I'm 
>>> developing on, nothing comes up ;)
>>>
>>> Even with a real IDE, if you have 10 declarations like this on the same 
>>> page, you will need 10 mice to hover over all of them to understand the 
>>> relationships ;)
>>>
>> It seems unlikely to have 10 declarations that have the same syntax so as 
>> to be confused with arrays. But I see your point.
>> I think an IDE can help further by using (semantic) highlighting: have the 
>> brackets for template instantiations highlighted differently, for example, 
>> in bold. It's not too difficult to implement, technically. (and it might 
>> be useful even for other template syntaxes, like the current !() )
> 
> 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 think this is really a deal killer for the bracket syntax.  Especially 
>>> since what we have already works so well.  Note that Identifier2 is going 
>>> to be a non-templated type regardless of whether you are declaring an AA 
>>> or a template instance, which makes it even more ambiguous.
>>>
>>> I can also see cases where someone thinks they are creating a template 
>>> instance, but didn't use the right template identifier, so then the 
>>> compiler now compiles the code as if they declared an AA.  I think Walter 
>>> wrote an article about things like this, something in response to people 
>>> requesting that semicolons be optional.
>> Eh, that could happen in a myriad of other situations. For example using 
>> one AA type instead of another type. But I don't think it's much 
>> significant, as the error will trivially be caught in most situations at 
>> compile time, when you try to use the type.
> 
> 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.


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D