Bill Baxter wrote:
> Trevor Parscal wrote:
>> == Quote from Walter Bright (newshound@digitalmars.com)'s article
>>> I have a bit of a problem with .. vs ..., I think they both look too
>>> similar  making it hard to review code for correctness, and I'd have a
>>> hard time remembering which means which, another source of bugs.
>>
>> Perhaps you guys aren't keen on the .. and ...
>>
>> But it would be nice to have some symbol mean "through" in ranges to acompany the
>> current .. which means "until"
>>
>> Like..
>>
>> 0 _ 5 == 0, 1, 2, 3, 4, 5
>> 0 .. 5 == 0, 1, 2, 3, 4
>>
>> Sorry - I know there's more important things to do.... Just puting my 2 cents in...
> 
> __ is a legal identifier though, so you'd need spaces to use it generally.
> 

Additionally, this
    1_5
would be interpreted as the number 15, since D ignores underscores that appear in the middle of numerical literals.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org

Bradley Smith wrote:

>> Maybe
>> 
>>   arr[2~~3] -- two dots stretch out and squgglified?
>>   arr[2**2] -- two dots gone hairy?
>>   arr[2::3] -- two dots .. on top of two dots ..
>>   arr[2``3] -- closest you can get to two dots up high
>>   arr[2##3] -- eh..
>>   arr[N@@B] -- heh heh
>> 
> 
> I noticed that ~~ is listed as a token on the Lexical page (http://www.digitalmars.com/d/lex.html), but I can't find reference to it anywhere else. What is ~~ used for?

An artifact from the regex match expression I think.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Alexander Panek wrote:
> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
> 

What about leaving ... as is and using ..+, or ...+, for inclusive?

Mike Parker escribió:
> Alexander Panek wrote:
>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>
> 
> What about leaving ... as is and using ..+, or ...+, for inclusive?

I think the best approach is to use standard mathematical notation:

array[1 .. 5] == 1, 2, 3, 4, 5
array(1 .. 5] == 2, 3, 4, 5
array[1 .. 5) == 1, 2, 3, 4
array(1 .. 5) == 2, 3, 4

There's no confusion there when you know mathematical ranges. The only problem is it's a confusion to the compiler... maybe?

Mike Parker wrote:
> Alexander Panek wrote:
> 
>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>
> 
> What about leaving ... as is and using ..+, or ...+, for inclusive?

Ooh, how about:
  [1..=3]

just like for loops, the difference between inclusive and exclusive is one '=' sign

  for (i=0; i<10; i++) ... // exclusive
  for (i=0; i<=10; i++) ...// inclusive

I thing the meaning of a..=b would be   easier to guess and remember.

--bb

Ary Manzana wrote:
> Mike Parker escribió:
>> Alexander Panek wrote:
>>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>>
>>
>> What about leaving ... as is and using ..+, or ...+, for inclusive?
> 
> I think the best approach is to use standard mathematical notation:
> 
> array[1 .. 5] == 1, 2, 3, 4, 5
> array(1 .. 5] == 2, 3, 4, 5
> array[1 .. 5) == 1, 2, 3, 4
> array(1 .. 5) == 2, 3, 4
> 
> There's no confusion there when you know mathematical ranges. The only problem is it's a confusion to the compiler... maybe?

well if compiler issues are no issues, than the most explicit would be:

array[1 .. 5] == 1,2,3,4,5
array]1 .. 5] ==   2,3,4,5
array[1 .. 5[ == 1,2,3,4
array]1 .. 5[ ==   2,3,4

roel

rm escribió:
> Ary Manzana wrote:
>> Mike Parker escribió:
>>> Alexander Panek wrote:
>>>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>>>
>>>
>>> What about leaving ... as is and using ..+, or ...+, for inclusive?
>>
>> I think the best approach is to use standard mathematical notation:
>>
>> array[1 .. 5] == 1, 2, 3, 4, 5
>> array(1 .. 5] == 2, 3, 4, 5
>> array[1 .. 5) == 1, 2, 3, 4
>> array(1 .. 5) == 2, 3, 4
>>
>> There's no confusion there when you know mathematical ranges. The only problem is it's a confusion to the compiler... maybe?
> 
> well if compiler issues are no issues, than the most explicit would be:
> 
> array[1 .. 5] == 1,2,3,4,5
> array]1 .. 5] ==   2,3,4,5
> array[1 .. 5[ == 1,2,3,4
> array]1 .. 5[ ==   2,3,4
> 
> roel

Very nice!!

The problem with "array(1 .. 5)" is it could look like a method call. But I guess the compiler could peak past the first expression after the '(' to see if it's a "..", so then it's a range expression. With "array]1 .. 5[" the compiler inmediately knows it's a range expression.

But I don't know if yours is the most explicit. In mathematics the parenthesis is used to exclude a number in a range, not the inverted bracket.

Anyway, it would be *great* if any of this is implemented. This way we benefit from two things:
- More expressiveness in the language.
- You don't have to remember that "[1 .. 5]" actually means "1, 2, 3, 4" (at first glance it looks like "1, 2, 3, 4, 5" to me), which could lead to bugs.

"opSlice" should be called in any of the four cases, the compiler should choose the appropiate value to send to the method depending on the brackets/parenthesis used, but "opSplice" should be aware that the first number is inclusive, the last is exclusive (just like now). Changing this convention could break a lot of old code.

Ary Manzana escribió:
> "opSlice" should be called in any of the four cases, the compiler should choose the appropiate value to send to the method depending on the brackets/parenthesis used, but "opSplice" should be aware that the first number is inclusive, the last is exclusive (just like now). Changing this convention could break a lot of old code.

Ouch, forgot to mention: changing the meaning of "[1 .. 5]" breaks old code. :-(

Good point! Has my vote.

Bill Baxter wrote:
> Mike Parker wrote:
>> Alexander Panek wrote:
>>
>>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>>
>>
>> What about leaving ... as is and using ..+, or ...+, for inclusive?
> 
> Ooh, how about:
>   [1..=3]
> 
> just like for loops, the difference between inclusive and exclusive is one '=' sign
> 
>   for (i=0; i<10; i++) ... // exclusive
>   for (i=0; i<=10; i++) ...// inclusive
> 
> I thing the meaning of a..=b would be   easier to guess and remember.
> 
> --bb

rm wrote:
> Ary Manzana wrote:
>> Mike Parker escribió:
>>> Alexander Panek wrote:
>>>> I'd really like to have a distinction between exclusive and inclusive slicing. Maybe '..'(inclusive) and '..-'(exclusive) or similar, with '..' => '..-'. Not *that* beautiful, though .. maybe someone has a better suggestion.
>>>>
>>>
>>> What about leaving ... as is and using ..+, or ...+, for inclusive?
>>
>> I think the best approach is to use standard mathematical notation:
>>
>> array[1 .. 5] == 1, 2, 3, 4, 5
>> array(1 .. 5] == 2, 3, 4, 5
>> array[1 .. 5) == 1, 2, 3, 4
>> array(1 .. 5) == 2, 3, 4
>>
>> There's no confusion there when you know mathematical ranges. The only problem is it's a confusion to the compiler... maybe?
> 
> well if compiler issues are no issues, than the most explicit would be:
> 
> array[1 .. 5] == 1,2,3,4,5
> array]1 .. 5] ==   2,3,4,5
> array[1 .. 5[ == 1,2,3,4
> array]1 .. 5[ ==   2,3,4
> 
> roel

so a[b[1..5].length]

would become a[b]1..4[.length]
??