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

[Yigal Chripun]

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

perhaps this will allow to remove AAs and arrays from the core language
and put them in the stdlib instead.
besides,there were discussions of separating arrays who own memory from
slices that don't.