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

[Yigal Chripun]

Alix Pexton wrote:
> Don wrote:
>> Robert Fraser wrote:
>>> Don wrote:
>>>> Bruno Medeiros wrote:
>>>>> Jason House wrote:
>>>>>> Bruno Medeiros 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> It may be easy to parse, but it isn't easy to read.
>>>>>>
>>>>>> What is goban[19]?  Is it an array or a template?  I'd hate to be
>>>>>> reading
>>>>>> through somebody else's code and have to decipher what things mean.
>>>>>
>>>>> I give the same answer I gave to Bill:
>>>>>
>>>>> True, you'd have to follow /goban/ to find out. But that is just a
>>>>> hover of the mouse away. :)
>>>>>
>>>>>
>>>>> Just for the record, I'm also not bothered by !(), but if some
>>>>> people really find the urge to change it, I'd much rather have
>>>>> brackets than the ugly sad pirate. I say ugly because the dot is
>>>>> much more common than the '!', and for me it has a more solidified
>>>>> meaning of accessing members, so seeing it used as part of the
>>>>> template instantiation syntax looks weird.
>>>>>
>>>> That's my opinion, too.
>>>>
>>>> Using square brackets would certainly fit with Walter's goal of
>>>> making templates less threatening for newcomers.
>>>> It would be pretty cool to teach a newbie:
>>>>
>>>> int[] a;
>>>> int[double] b;  // this is an AA
>>>> priorityqueue[double] c; // this is a template
>>>
>>> I can't tell if you're being sarcastic here or not...
>>
>> I would never intentionally use sarcasm on a group containing
>> non-native English speakers.
>> I think there's a genuine similarity between AAs and templates,
>> providing a natural teaching progression.
>>
> 
> Um, b (the int[double] AA above) is a collection of ints that is indexed
> by a double. But is c a collection of priorityqueues that are indexed by
> a double? To me, that doesn't make sense, what type of data can I add to
> it? what type is used so set the priority? Further, I don't think it
> would make sense to use square-braces to invoke templates that are not
> collections, those that take multiple parameters or one that isn't a
> type. To me, it seems like this would make templates seem more
> complicated to new users.
> 
> A...
as already noted by others, Andrei wanted to write Array!(T) with a
capacity field. using that the above would hopefully evolve to:

 Array[int] a; // used to be - int[] a;
 Array[SomeType, 4, 4, 4] d; //used to be SomeType[4][4][4] d;
 AssociativeArray[int, double] b; // used to be - int[double] b;
 PriorityQueue[double] c; // this remains a template

all of the above would be templates.

Andrei is also working on Range templates, which I think generalize the
array slice feature. with that, the current use of [] with types can be
deprecated.

my personal feeling is that the above syntax would be easier for
newbies. either you use it as slicing operator which returns a range or
as template parameter list.