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

[Bill Baxter]

On Mon, Oct 20, 2008 at 7:07 PM, Yigal Chripun <yigal100 at gmail.com> wrote:
> 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.

Don't arrays have to be built-ins to work with CTFE and various
template/tuple usages?  So if Array will gain that sort of built-in
status then Array will effectively become a new keyword in the
language.   But honestlly the two new keywords wouldn't bother me as
much as  having to type those names out all the time.

--bb