foo!(bar) ==> foo{bar} ==> foo[bar] (just Brackets)
Steven Schveighoffer
schveiguy at yahoo.com
Mon Oct 20 08:33:32 PDT 2008
"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...
>
>> 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.
While the bracket syntax is attractive, it's too close to array
declarations. I know Andrei has proposed declaring builtin arrays as
Array!(X) (or in this case it would be Array[X]), but I hope that never
happens, the current syntax for arrays is perfect, and I hope Walter agrees
with that...
-Steve
More information about the Digitalmars-d
mailing list