> It's a nice proposal, but what happens if you want a range of floats, e.g., 1.0..2.0?

Correct me if I'm wrong, parsing would look like:

----------------------------------------
1.0..2.0
===      Found a literal.

1.0..2.0
   ==    Found a binary operator.

1.0..2.0
     === Found a literal.
----------------------------------------

Something like `5....5` could also compile (since there's only 1 valid parsing), though such a thing is clearly an abomination, so I'd write it `5. .. .5` or `(5.)..(.5)`.  The whole ordeal is probably a bit of insight into why other languages use the ':' character for slicing.

replace .. with : to make lexing easier, please

On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
> replace .. with : to make lexing easier, please

	auto b = arr[(someCondition) ? w:x : y:z];

:-(


T

-- 
Computers aren't intelligent; they only think they are.

On 03/17/2014 11:24 PM, H. S. Teoh wrote:
> On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
>> replace .. with : to make lexing easier, please
> 	auto b = arr[(someCondition) ? w:x : y:z];
>
> :-(
>
>
> T
>
Thats a parsing problem.

1..1 makes you think you got a prefix of a float 1. but actually you got an int slice_operator int. If there where no .. flex like generator could handle D, at least as far as I can see it.

On Mon, Mar 17, 2014 at 11:33:38PM +0100, Robert Schadek wrote:
> On 03/17/2014 11:24 PM, H. S. Teoh wrote:
> > On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
> >> replace .. with : to make lexing easier, please
> > 	auto b = arr[(someCondition) ? w:x : y:z];
> >
> > :-(
> >
> >
> > T
> >
> Thats a parsing problem.
> 
> 1..1 makes you think you got a prefix of a float 1. but actually you got an int slice_operator int. If there where no .. flex like generator could handle D, at least as far as I can see it.

Point.

But still, syntax that makes lexing or parsing hard -- that scores against this DIP.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL

On 03/17/2014 11:37 PM, H. S. Teoh wrote:
>> >1..1 makes you think you got a prefix of a float 1. but actually you
>> >got an int slice_operator int. If there where no .. flex like
>> >generator could handle D, at least as far as I can see it.
> Point.
>
> But still, syntax that makes lexing or parsing hard -- that scores
> against this DIP.
>

No, it does not. The lexer does not need to change.

On Monday, 17 March 2014 at 22:21:46 UTC, Robert Schadek wrote:
> replace .. with : to make lexing easier, please

+1

On Monday, 17 March 2014 at 22:26:05 UTC, H. S. Teoh wrote:
> On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
>> replace .. with : to make lexing easier, please
>
> 	auto b = arr[(someCondition) ? w:x : y:z];
>
> :-(
>
>
> T

Julia has both the ternary conditional and ":" as an operator.  In practice, they rarely come up in the same expressions, and when they do, parentheses are an easy solution.

    auto b = arr[someCondition ? (w:x) : (y:z)];

However, I think it's worth mentioning that--unless I've missed something--DIP58 doesn't introduce any parsing issues that aren't already present inside a SliceExpression:

    struct S { void opSlice(real a, real b) {} }

    S s;
    s[5. .. .5]; // Compiles.
    s[5... .5]; // Error.
    s[5. ...5]; // Error.
    s[5....5]; // Error.

This seems like reasonable behavior, in my opinion.

It seems like ":" and ".." both have their pros and cons, but ".." allows backwards compatibility to be preserved, and I don't see how ":" can be worked in elegantly without breaking lots of code.

On 03/17/2014 11:43 PM, Timon Gehr wrote:
> No, it does not. The lexer does not need to change.
you're right, but at some distant  future I would like .. to be replaced by :

On 17.03.2014 23:33, Robert Schadek wrote:
> On 03/17/2014 11:24 PM, H. S. Teoh wrote:
>> On Mon, Mar 17, 2014 at 11:16:12PM +0100, Robert Schadek wrote:
>>> replace .. with : to make lexing easier, please
>> 	auto b = arr[(someCondition) ? w:x : y:z];
>>
>> :-(
>>
>>
>> T
>>
> Thats a parsing problem.
>
> 1..1 makes you think you got a prefix of a float 1. but actually you got
> an int slice_operator int. If there where no .. flex like generator
> could handle D, at least as far as I can see it.
>

".." is a tiny problem regarding lexing in comparison to all the string types in D. How do you deal with DelimitedString and TokenString (http://dlang.org/lex#DelimitedString) when using a lexer generator?