Stewart Gordon:
> But in D, you can use a negative index/key in an AA or custom array type.

This is natural & easy to do in Python too.


> And is there any equivalent in Python to a[$/2] or anything fancy like that?

You have to do it in explicit way:
a[len(a) / 2]
Or today better (// is the integer division):
a[len(a) // 2]

Bye,
bearophile

On 2009-11-19 15:46:57 -0800, Bill Baxter <wbaxter@gmail.com> said:

> On Wed, Nov 18, 2009 at 8:33 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> I am thinking that representing operators by their exact token
>> representation is a principled approach because it allows for unambiguous
>> mapping,
> 
> There used to be an argument floating around that using 'opAdd" was
> better than "op+" because the former encourages people to only
> overload the method to do things that resemble addition.  Whereas op+
> says I'm just a symbol, do whatever you want with me.
> 
> I never really bought into it... but it was what I was told years ago
> when I complained that opSub opMul etc were harder to remember than
> need be. :-)
> I guess D will have to change it's story now.
> 
> --bb

The reason Walter provided me when I asked ~9 years ago was that "T operator+(T)" causes unnecessary headaches when parsing.  opAdd does not produce these complications when parsing function declarations.

T opBinary(string op)(T) also does not produce the same headaches.

-SC

On 2009-11-20 02:18:03 -0800, Pelle Månsson <pelle.mansson@gmail.com> said:

> Andrei Alexandrescu wrote:
>> Bill Baxter wrote:
>>> On Thu, Nov 19, 2009 at 8:46 AM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org> wrote:
>>>> grauzone wrote:
>>>>> What's with opSomethingAssign (or "expr1[expr2] @= expr3" in general)?
>>>>> opBinary doesn't seem to solve any of those.
>>>> opBinary does solve opIndex* morass because it only adds one function per
>>>> category, not one function per operator. For example:
>>>> 
>>>> struct T {
>>>>    // op can be "=", "+=", "-=" etc.
>>>>    E opAssign(string op)(E rhs) { ... }
>>>>    // op can be "=", "+=", "-=" etc.
>>>>    E opIndexAssign(string op)(size_t i, E rhs) { ... }
>>>> }
>>> 
>>> Rewrite
>>> a.prop = x;   =>    a.opPropertyAssign!("prop", "=")(x);
>>> 
>>> to that and we're really getting somewhere!
>>> 
>>> --bb
>> 
>> I swear I was thinking of that.
>> 
>> Andrei
> Is this doable without a performance drop?

These are compile-time string mixin magic.   It might make your code compile slower, but the metaprogramming engine in D is already 1000000000x faster than C++.

lws Wrote:

> On 2009-11-19 15:46:57 -0800, Bill Baxter <wbaxter@gmail.com> said:
> 
> > On Wed, Nov 18, 2009 at 8:33 PM, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> > 
> >> I am thinking that representing operators by their exact token representation is a principled approach because it allows for unambiguous mapping,
> > 
> > There used to be an argument floating around that using 'opAdd" was better than "op+" because the former encourages people to only overload the method to do things that resemble addition.  Whereas op+ says I'm just a symbol, do whatever you want with me.
> > 
> > I never really bought into it... but it was what I was told years ago
> > when I complained that opSub opMul etc were harder to remember than
> > need be. :-)
> > I guess D will have to change it's story now.
> > 
> > --bb
> 
> The reason Walter provided me when I asked ~9 years ago was that "T operator+(T)" causes unnecessary headaches when parsing.  opAdd does not produce these complications when parsing function declarations.
> 
> T opBinary(string op)(T) also does not produce the same headaches.
> 
> -SC
> 

There is a page for the rational which I thought gave the OP's explination:

http://digitalmars.com/d/2.0/rationale.html

However it does have this nice little gem:

"__ keywords should indicate a proprietary language extension, not a basic part of the language."

Which makes you wonder why D has __traits, __gshared... or are those not basic parts of the language? :)

On Dec 16, 09 07:21, Jesse Phillips wrote:
> lws Wrote:
>
>> On 2009-11-19 15:46:57 -0800, Bill Baxter<wbaxter@gmail.com>  said:
>>
>>> On Wed, Nov 18, 2009 at 8:33 PM, Andrei Alexandrescu
>>> <SeeWebsiteForEmail@erdani.org>  wrote:
>>>
>>>> I am thinking that representing operators by their exact token
>>>> representation is a principled approach because it allows for unambiguous
>>>> mapping,
>>>
>>> There used to be an argument floating around that using 'opAdd" was
>>> better than "op+" because the former encourages people to only
>>> overload the method to do things that resemble addition.  Whereas op+
>>> says I'm just a symbol, do whatever you want with me.
>>>
>>> I never really bought into it... but it was what I was told years ago
>>> when I complained that opSub opMul etc were harder to remember than
>>> need be. :-)
>>> I guess D will have to change it's story now.
>>>
>>> --bb
>>
>> The reason Walter provided me when I asked ~9 years ago was that "T
>> operator+(T)" causes unnecessary headaches when parsing.  opAdd does
>> not produce these complications when parsing function declarations.
>>
>> T opBinary(string op)(T) also does not produce the same headaches.
>>
>> -SC
>>
>
> There is a page for the rational which I thought gave the OP's explination:
>
> http://digitalmars.com/d/2.0/rationale.html
>
> However it does have this nice little gem:
>
> "__ keywords should indicate a proprietary language extension, not a basic part of the language."
>
> Which makes you wonder why D has __traits, __gshared... or are those not basic parts of the language? :)

__gshared was deliberately named to discourage its use iirc.

KennyTM~ Wrote:

> On Dec 16, 09 07:21, Jesse Phillips wrote:
> >
> > http://digitalmars.com/d/2.0/rationale.html
> >
> > However it does have this nice little gem:
> >
> > "__ keywords should indicate a proprietary language extension, not a basic part of the language."
> >
> > Which makes you wonder why D has __traits, __gshared... or are those not basic parts of the language? :)
> 
> __gshared was deliberately named to discourage its use iirc.

Yes, which makes things even more inconsistent.

__ indicates proprietary language extension
__ we don't want you using this much (__gshared)
__ this way we aren't adding a keyword to the standard namespace (__traits)

At least those have been the reasons I've heard. This makes __ absolutely meaningless and good at making things ugly.

On 15/12/09 23:21, Jesse Phillips wrote:
> There is a page for the rational which I thought gave the OP's explination:
>
> http://digitalmars.com/d/2.0/rationale.html
>
> However it does have this nice little gem:
>
> "__ keywords should indicate a proprietary language extension, not a basic part of the language."
>
> Which makes you wonder why D has __traits, __gshared... or are those not basic parts of the language? :)

I'd drop this in bugzilla, I think this needs addressing before D2 is released :)

On 12/16/2009 2:36 PM, Jesse Phillips wrote:
> __ indicates proprietary language extension
> __ we don't want you using this much (__gshared)
> __ this way we aren't adding a keyword to the standard namespace (__traits)
> 
> At least those have been the reasons I've heard. This makes __ absolutely meaningless and good at making things ugly.

That’s actually the best reason: “__” makes things ugly, so the community is moved to find a cleaner way to express what these identifiers signify.

—Joel Salomon