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

[Bruno Medeiros]

Steven Schveighoffer wrote:
> "Bruno Medeiros" wrote
>> Bill Baxter wrote:
>>> On Thu, Oct 16, 2008 at 12:24 AM, Jesse Phillips
>>> <jessekphillips at gmail.com> wrote:
>>>> On Wed, 15 Oct 2008 11:24:46 +0100, Bruno Medeiros wrote:
>>>>
>>>>> Jarrett Billingsley wrote:
>>>>>> On Tue, Oct 14, 2008 at 6:43 PM, Bruno Medeiros
>>>>>> <brunodomedeiros+spam at com.gmail> wrote:
>>>>>>> Don wrote:
>>>>>>>> Denis Koroskin wrote:
>>>>>>>>> On Wed, 08 Oct 2008 18:22:21 +0400, superdan <super at dan.org> wrote:
>>>>>>>>>
>>>>>>>>>> Walter Bright Wrote:
>>>>>>>>>>
>>>>>>>>>>> Dee Girl wrote:
>>>>>>>>>>>> I did not follow this group recent. School started. Sorry! I 
>>>>>>>>>>>> just
>>>>>>>>>>>> see now and please add my vote if possible. I start with D 
>>>>>>>>>>>> recent
>>>>>>>>>>>> and I remember beginning. foo!(bar) was not pleasant. Like 
>>>>>>>>>>>> forced
>>>>>>>>>>>> convention with a bad char. And friends I show code never like
>>>>>>>>>>>> it. It is first thing they say why they do not like D. For me
>>>>>>>>>>>> foo{bar} better idea. Thank you, Dee Girl
>>>>>>>>>>> What do your friends think of { } ?
>>>>>>>>>> School started. Every one so busy now. But I think does not matter
>>>>>>>>>> any more ^_^
>>>>>>>>>>
>>>>>>>>>> I want to make little idea. Sorry if idea mentioned before (I did
>>>>>>>>>> not read every thread). I think we can look square brackets []. 
>>>>>>>>>> Let
>>>>>>>>>> me explain why.
>>>>>>>>>>
>>>>>>>>>> Paren () is over used in C and in D. Any expression can be in ().
>>>>>>>>>> And adding () is possible in many cases. But it is not same with
>>>>>>>>>> []. For example a:(b) is ambiguous but a:[b] is not. So there are
>>>>>>>>>> many signs possible after symbol and before [. They are:
>>>>>>>>>>
>>>>>>>>>> ~ ! @ # $ % ^ & * - + = | \ / , < . > ? :
>>>>>>>> Not all of them work. Here's a few examples:
>>>>>>>>
>>>>>>>>    enum { d= 3, e = 7 }
>>>>>>>>    int [] a=[1,2];
>>>>>>>>    bool c;
>>>>>>>>    auto k=[e]; // kills =
>>>>>>>>    a ~= c?[d]:[e]; // kills ?
>>>>>>>>    int [] f = c?k:[e]; // kills :
>>>>>>>>    if (f>[e]) {}   // kills <
>>>>>>>>    if (f<[e]) {}   // kills >
>>>>>>>>    auto g = (k,[d]); // kills comma
>>>>>>>>    auto h = k~[d]; // kills ~
>>>>>>>>
>>>>>>>> Array ops will kill + - * / & | % ^
>>>>>>>> Suddenly the list looks pretty short. !@#$\.
>>>>>>> Hum, what about brackets without any prefix character at all?
>>>>>>>
>>>>>>>  Vector[int, 2] foo;
>>>>>>>  List[Vector[int, 2]] bar;
>>>>>>>  int[3] a = [1, 2, 3]; // array literal here int[int] map;
>>>>>>>  alias DenseMatrix[num] PulType;
>>>>>>>  alias SparseRowsMatrix[num, HashSparseVector] PuuType; alias
>>>>>>>  BiMap[uint, Tuple[uint, uint], BiMapOptions.lhDense] DicType; int 
>>>>>>> var
>>>>>>>  = a[2]; // array indexing here
>>>>>>>
>>>>>>> Hum... doesn't look bad visually. In fact it seems to fit quite nice
>>>>>>> with how associative arrays, and even normal arrays, are declared.
>>>>>>> Hum, yes, I'm personally liking this a lot.
>>>>>>>
>>>>>>> But does it have any ambiguities? Hum, can't think of any off-hand. 
>>>>>>> If
>>>>>>> an identifier appears before a bracket list, it could either be a
>>>>>>> template instantiation, or an array indexation. But the syntax of 
>>>>>>> both
>>>>>>> is the same, so it doesn't need to be distinguished in the parser.
>>>>>>>
>>>>>>> Waddya think, was this discussed before?
>>>>>> Erm,
>>>>>>
>>>>>> SomeClass[3] a; // template or array?
>>>>> What about it? It doesn't matter for the parser to know if SomeClass is
>>>>> a template or array, it can just keep parsing. Its not like the "class 
>>>>> A
>>>>> : B { }" where parsing would continue differently if B was a template
>>>>> instead of a type.
>>>> Personally, it is important that I can parse it as a template or array. 
>>>> I
>>>> prefer the !() syntax, it makes it incredibly easy to find creations of 
>>>> a
>>>> template.
>>> I think you may be right.  If nothing technical against it emerges,
>>> the human will likely be the weak link here.
>>>
>>> More than SomeClass[3], this is the case that worries me:
>>>
>>>    Identifier1[Identifier2]  x;
>>>
>>> is it an AA or a templated type?
>>>
>>> --bb
>> True, you'd have to follow Identifier1 to find out. But that is just a 
>> hover of the mouse away. :)
> 
> 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 !() )

> 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.
> 
> -Steve 
> 
> 

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.

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