Nick Sabalausky wrote:
>  Someone else said it's also an expression
> that evaluates to 3, but that seems beyond useless to me. 

It's handy when you want to prefix one expression to another, as in:

   (foo(), x + 3)

Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> Andrei Alexandrescu wrote:
>>> Now there are several problems with this. All of the following compile:
>>
>> Possible solution: treat all sequences as dots as part of the same
>> token, always.
>>
>>> 0.....wyda
>>> 0....wyda
>>> 0.... wyda
>>> 0... .wyda
>>> 0.. .wyda
>>> 0. ....wyda
>>
>> All rejected by the lexer.
> 
> No. Actually, some, yes :o).

I think he meant those /could/ be made to be rejected by the lexer. At least rejecting more than three consecutive dots leaves you with:

0... .wyda
0.. .wyda

which are ok. Also "0." and the like should be rejected.

> 
>>> 0. .. .wyda
>>> 0. ...wyda
>>
>> Legal and unambiguous.
> 
> And throroughly confusing, which was my point.

The ".name" syntax and the "number." are the things that are confusing, not the inclusive/exclusive ranges.

Ary Borenszweig wrote:
> Andrei Alexandrescu wrote:
>> Rainer Deyke wrote:
>>> Andrei Alexandrescu wrote:
>>>> Now there are several problems with this. All of the following compile:
>>>
>>> Possible solution: treat all sequences as dots as part of the same
>>> token, always.
>>>
>>>> 0.....wyda
>>>> 0....wyda
>>>> 0.... wyda
>>>> 0... .wyda
>>>> 0.. .wyda
>>>> 0. ....wyda
>>>
>>> All rejected by the lexer.
>>
>> No. Actually, some, yes :o).
> 
> I think he meant those /could/ be made to be rejected by the lexer.

Hack the lexer to support a useless and dangerous feature? Now we got something going.

> At least rejecting more than three consecutive dots leaves you with:
> 
> 0... .wyda
> 0.. .wyda
> 
> which are ok. Also "0." and the like should be rejected.

Yup, more gratuitous changes to the language. We are left with "the little space that could change everything".

>>
>>>> 0. .. .wyda
>>>> 0. ...wyda
>>>
>>> Legal and unambiguous.
>>
>> And throroughly confusing, which was my point.
> 
> The ".name" syntax and the "number." are the things that are confusing, not the inclusive/exclusive ranges.

The .name syntax and the number. syntax are confusing. Using "..." as a separator multiplies confusion by a billion.


Andrei

Ary Borenszweig Wrote:

> > 
> > to? really, no, it needs to be -
> > 
> > switch (var) {
> >     case 0:
> >         break;
> > 
> >     case 1 - 5:
> >         break;
> > }
> 
> Is that a joke?

No, I just hope it won't be taken seriously. :)

On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Nick Sabalausky wrote:
>>
>>  Someone else said it's also an expression
>> that evaluates to 3, but that seems beyond useless to me.
>
> It's handy when you want to prefix one expression to another, as in:
>
>   (foo(), x + 3)

Cause you want to do that so often, after all.

*snort*

On Tue, Jul 7, 2009 at 3:49 PM, Jarrett Billingsley<jarrett.billingsley@gmail.com> wrote:
> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>> Nick Sabalausky wrote:
>>>
>>>  Someone else said it's also an expression
>>> that evaluates to 3, but that seems beyond useless to me.
>>
>> It's handy when you want to prefix one expression to another, as in:
>>
>>   (foo(), x + 3)
>
> Cause you want to do that so often, after all.
>
> *snort*

A more constructive reply: tuuuuples.  TUPLES.  Returning them!  Using them as first-class values!  Yes.

Jarrett Billingsley wrote:
> On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
> Billingsley<jarrett.billingsley@gmail.com> wrote:
>> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>> Nick Sabalausky wrote:
>>>>  Someone else said it's also an expression
>>>> that evaluates to 3, but that seems beyond useless to me.
>>> It's handy when you want to prefix one expression to another, as in:
>>>
>>>   (foo(), x + 3)
>> Cause you want to do that so often, after all.
>>
>> *snort*
> 
> A more constructive reply: tuuuuples.  TUPLES.  Returning them!  Using
> them as first-class values!  Yes.

Just prepend "tuple" and you're home at a low price.

Andrei

On Tue, Jul 7, 2009 at 4:15 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> Jarrett Billingsley wrote:
>>
>> On Tue, Jul 7, 2009 at 3:49 PM, Jarrett Billingsley<jarrett.billingsley@gmail.com> wrote:
>>>
>>> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>>
>>>> Nick Sabalausky wrote:
>>>>>
>>>>>  Someone else said it's also an expression
>>>>> that evaluates to 3, but that seems beyond useless to me.
>>>>
>>>> It's handy when you want to prefix one expression to another, as in:
>>>>
>>>>  (foo(), x + 3)
>>>
>>> Cause you want to do that so often, after all.
>>>
>>> *snort*
>>
>> A more constructive reply: tuuuuples.  TUPLES.  Returning them!  Using them as first-class values!  Yes.
>
> Just prepend "tuple" and you're home at a low price.

I can't return tuples.  I have to wrap them in a struct.  If I do that, then I can't index the struct as if it were a real tuple.  Okay, then I use 'alias this', and I end up with this struct that exists for no purpose other than to get around a silly limitation in the type system.  Well, geez!  Why not just make tuples first-class?

Jarrett Billingsley wrote:
> On Tue, Jul 7, 2009 at 4:15 PM, Andrei
> Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
>> Jarrett Billingsley wrote:
>>> On Tue, Jul 7, 2009 at 3:49 PM, Jarrett
>>> Billingsley<jarrett.billingsley@gmail.com> wrote:
>>>> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com>
>>>> wrote:
>>>>> Nick Sabalausky wrote:
>>>>>>  Someone else said it's also an expression
>>>>>> that evaluates to 3, but that seems beyond useless to me.
>>>>> It's handy when you want to prefix one expression to another, as in:
>>>>>
>>>>>  (foo(), x + 3)
>>>> Cause you want to do that so often, after all.
>>>>
>>>> *snort*
>>> A more constructive reply: tuuuuples.  TUPLES.  Returning them!  Using
>>> them as first-class values!  Yes.
>> Just prepend "tuple" and you're home at a low price.
> 
> I can't return tuples.  I have to wrap them in a struct.  If I do
> that, then I can't index the struct as if it were a real tuple.  Okay,
> then I use 'alias this', and I end up with this struct that exists for
> no purpose other than to get around a silly limitation in the type
> system.  Well, geez!  Why not just make tuples first-class?

Yeah, really. The TupleType already exists in the compiler, but just can't be expressed and passed around in the language.

I had trouble with this in Descent, for example:

auto x = Foo.tupleof;

Now you hover over "auto" and it should show you the type, but... the type is magical! That was when I found out about tuples. Now I show that as "Tuple!(...)", which is incorrect because it's not a template, but the language can't represent tuples.

So there should be a syntax to represent tuples also...

Jarrett Billingsley wrote:
> On Tue, Jul 7, 2009 at 3:38 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>> Nick Sabalausky wrote:
>>>  Someone else said it's also an expression
>>> that evaluates to 3, but that seems beyond useless to me.
>> It's handy when you want to prefix one expression to another, as in:
>>
>>   (foo(), x + 3)
> 
> Cause you want to do that so often, after all.
> 
> *snort*

It happens less manually and more when you're generating code. The latter happens a lot.