http://dlang.org/abi.html

This is undocumented - and probably should be raised as a bug as is not defined.

Thanks
Iain.

On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:
> http://dlang.org/abi.html
>
> This is undocumented - and probably should be raised as a bug as is not defined.
>
> Thanks
> Iain.

Aren't supposed to go away at some point ?

On Friday, 22 February 2013 at 13:44:09 UTC, deadalnix wrote:
> On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:
>> http://dlang.org/abi.html
>>
>> This is undocumented - and probably should be raised as a bug as is not defined.
>>
>> Thanks
>> Iain.
>
> Aren't supposed to go away at some point ?

Maybe... but as they got added as being semantically valid in 2.061, requires minimal changes to make it handled by the compiler backend for gdc.


Single letters that not currently in use (as far as I can see):  N, Q, and z


Regards
Iain

On Friday, 22 February 2013 at 13:55:51 UTC, Iain Buclaw wrote:
> On Friday, 22 February 2013 at 13:44:09 UTC, deadalnix wrote:
>> On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:
>>> http://dlang.org/abi.html
>>>
>>> This is undocumented - and probably should be raised as a bug as is not defined.
>>>
>>> Thanks
>>> Iain.
>>
>> Aren't supposed to go away at some point ?
>
> Maybe... but as they got added as being semantically valid in 2.061, requires minimal changes to make it handled by the compiler backend for gdc.
>

Also, the current error is "cent and ucent types not implemented" - not "cent and ucent types not implemented, technically deprecated, and thus never will be, have a nice day *waves*"

deadalnix:

> Aren't supposed to go away at some point ?

I have never read an official statement of them going away, and
I'd like the cent/ucent types.

On the other hand Andrei has instead suggested to introduce a
fixnum struct in Phobos, that is able to replace a "cent" in many
cases (I don't know if he wants to replace ucent too):

alias cent = Fixnum!128;

Maybe such Fixnum risks being less efficient than a cent (unless
its operations get fully inlined, and this is quite possible if
it's a struct).

If there isn't a perfect inlining, then there is some lost
performance. A D compiler performs optimizations on built-in
integral numbers based on the mathematical properties of such
numbers.

Maybe a way to remove or reduce that lost inefficiency with a
user-defined integral struct value like Fixnum is to introduce in
D annotations like @commutative and @associativity that applied
to such struct definition allows the compiler to perform some
integral-related optimizations. The compiler is not able to
enforce that annotations like @commutative are actually correct
for the user code.

A more "big guns" approach is something like the Axioms that
weren't added to C++11, this is a quite interesting article:

http://akrzemi1.wordpress.com/2012/01/11/concept-axioms-what-for/

axioms allow you to write a concept for integers-like numbers,
usable for a Fixnum, that later the compiler is able to use to
perform those optimizations:


concept IntegerLike<typename T> : CopyConstructible<T> {
     T::T( int );
     T operator*( T, T );

     axiom Commutativity( T x, T y ) {
         x * y <=> y * x;
     }
     axiom Associativity( T x, T y, T z ) {
         (x * y) * z <=> x * (y * z);
     }
     axiom ValuePropagation( int x, int y ) {
         T(x) * T(y) <=> T(x * y);
     }
}


The advantage of @commutative and @associativity is that they are
probably simpler to implement. The disadvantage is that
concept+axiom is much more flexible, allowing you to model other
algebraic properties.

Bye,
bearophile

On Friday, February 22, 2013 14:44:08 deadalnix wrote:
> On Friday, 22 February 2013 at 13:31:18 UTC, Iain Buclaw wrote:
> > http://dlang.org/abi.html
> > 
> > This is undocumented - and probably should be raised as a bug as is not defined.
> > 
> > Thanks
> > Iain.
> 
> Aren't supposed to go away at some point ?

Why would they? They're set aside for the possibility of implementing 128 bit integers. If that never happens, then they'll never be used, but it probably will happen at some point, and they're reserved until then. I don't believe that either Walter or Andrei has ever suggested getting rid of them.

- Jonathan M Davis

Jonathan M Davis:

> I don't believe that either Walter or Andrei has ever
> suggested getting rid of them.

Andrei has suggested few times to implement a fixnum in Phobos instead of the built-in cent/ucent, and he was quite against a recent change that makes allows programmers to know if the current D compiler has implemented cent/ucent:

https://github.com/D-Programming-Language/dmd/pull/672

http://d.puremagic.com/issues/show_bug.cgi?id=785

Bye,
bearophile

"Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:yhylqjyqkfrebukidkfb@forum.dlang.org...
>>
>> Aren't supposed to go away at some point ?
>
> Maybe... but as they got added as being semantically valid in 2.061, requires minimal changes to make it handled by the compiler backend for gdc.
>

Not quite, they became syntactically valid only.

I guess just pick a couple of letters?

On Feb 23, 2013 3:57 AM, "Daniel Murphy" <yebblies@nospamgmail.com> wrote:
>
> "Iain Buclaw" <ibuclaw@ubuntu.com> wrote in message news:yhylqjyqkfrebukidkfb@forum.dlang.org...
> >>
> >> Aren't supposed to go away at some point ?
> >
> > Maybe... but as they got added as being semantically valid in 2.061, requires minimal changes to make it handled by the compiler backend for gdc.
> >
>
> Not quite, they became syntactically valid only.
>
> I guess just pick a couple of letters?
>
>

N and Q ?  That's pretty much what's left to choose from.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Iain Buclaw:

> N and Q ?  That's pretty much what's left to choose from.

Maybe "Nc" "Nu" for cent/ucent, and leave "Q" as a prefix for future additions?

Bye,
bearophile