December 11, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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 |
December 15, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | 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
|
December 15, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Pelle Månsson | 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++.
|
December 15, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to lws | 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? :) |
December 16, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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.
|
December 16, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | 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.
|
December 16, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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 :)
|
December 18, 2009 Re: Short list with things to finish for D2 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jesse Phillips | 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
|
Copyright © 1999-2021 by the D Language Foundation