"with" still sucks + removing features + adding features

[Alexander Pánek]

Andrei Alexandrescu wrote:
> Robert Fraser wrote:
>> Frank Benoit wrote:
>>> Alexander Pánek schrieb:
>>>> Andrei Alexandrescu wrote:
>>>>> bearophile wrote:
>>>>>> Andrei Alexandrescu:
>>>>>>
>>>>>> Thank you for bringing a "real" example that gives something to 
>>>>>> work on.
>>>>>>
>>>>>>> Awful!<
>>>>>> Well, one of your cases was wrong. Using the +1 at the end one of
>>>>>> those cases become:
>>>>>> case 'A' .. 'Z'+1, 'a' .. 'z'+1:
>>>>>> Instead of what you have written:
>>>>>> case 'A' .. 'Z'+1: case 'a' .. 'z'+1:
>>>>>>
>>>>>> I agree that that syntax with +1 isn't very nice looking. But the
>>>>>> advantage of +1 is that it introduces (almost) no new syntax, it's
>>>>>> not easy to miss, its meaning is easy to understand. AND you don't
>>>>>> have to remember that in a case the .. is inclusive while in foreach
>>>>>> is exclusive on the right, keeping the standard way in D to denote
>>>>>> ranges.
>>>>> You don't understand. My point is not that people will dislike 'Z'+1.
>>>>> They will FORGET TO WRITE THE BLESSED +1. They'll write:
>>>>>
>>>>> case 'A' .. 'Z':
>>>> You know, Ruby solves this by introducing a “seperate” range syntax for
>>>> exclusive ranges: “...”. An inclusive range is written the same as an
>>>> exclusive range in D: “..”.
>>>>
>>>> a[1 .. 2].length #=> 1 ([a[1]])
>>>> a[1 ... 2].length #=> 2 ([a[1], a[2]])
>>>>
>>>> I see no reason not to include such a seperate syntax in D. “..” being
>>>> exclusive and “...” being inclusive, not the other way round as in Ruby
>>>> — see “Programmer’s Paradox” @
>>>> http://www.programmersparadox.com/2009/01/11/ruby-range-mnemonic/ .
>>>>
>>>> Kind regards, Alex
>>>
>>> Yes, this is useful for all use cases of ranges.
>>> I like '...'.
>>
>> Indeed it's not a bad idea... But it might be easily mistyped, lead to 
>> strange off-by-one errors and be very difficult to find while 
>> debugging them. Hmmm...
> 
> It's an awful idea. It's a non-idea. If "idea" had an antonym, that 
> would be it.
> 
> I can't fathom what's on the mind of a person (not you, at least you
> foresee some potential problems) who, even after patiently explained the
> issues with this mental misfire, several times, still can bring
> themselves to think it's not that bad.

I don’t see a reason not to restrict other features to introduce a new 
one. I never used .foo to access the global scope or .1 for floating 
point literals. But what I do use very often is array[n..m + 1], which 
would ease things for quite a lot of things going on when working with 
arrays. Of course it’s just syntactic sugar, but so is the whole slicing 
feature. It could easily be done in the standard library.

So I’m not demanding anything, I’m just providing my very own thoughts 
on this topic. If there are too many obstacles then it’s probably not 
worth it. The thing is, I don’t know half as much as most of the guys 
here do, so I don’t see those obstacles at first glance. Please bear 
with me. :)

> Let me add one more, although more than sure someone will find a remedy
> for it, too.
> 
> a...b

inclusive range from a to b

> vs.
> 
> a.. .b

exclusive range from a to .b

Personally, I see “...” as an atomic operator, like “!=” or “==”. I 
wouldn’t ever recognize “.. .” as “...” or “! =” as “!=”. Additionally, 
I add a space before and after every operator, so there’s no ambiguity 
in any way, plus it’s nicely recognizable what the hell is going on. If 
it was for me, I’d even go as far as to make this a requirement in the 
specification. But that would upset downs.

Actually, what about “…” as inclusive range operator? :P I’d love that.


> and of course the beauty
> 
> a....b

Inclusive range from “a” to “.b”? Pretty clear in this *particular* case. ;)


> I don't plan to discuss minor features on this group anymore.

But.. bike shed discussions are fun! Seriously, though — I learn a lot 
thanks to people “nitpicking” other people’s ideas, showing corner 
cases, obstacles and so on. So please, don’t stop discussing minor 
features. :)