I'm asking this as a end user:

It was my understanding that cent/ucent where more or less abandoned as native types. But would it be possible to have Cent/UCent as library types?

We have Complex, and Walter recently proposed the HalfFloat type.

Why not Cent and UCent?

Is it too complex for library code? I'd suspect you need to catch overflow flags for efficient carry over, but D has built-in asm, so that shouldn't be too complicated... Should it?

Or do we already have some sort of generic (statically sized) big inter, eg:
Big!128 or UBig!128? Or if not, would we want that?

Should I open an ER for either of the two ideas?

On Monday, December 31, 2012 19:56:11 monarch_dodra wrote:
> I'm asking this as a end user:
> 
> It was my understanding that cent/ucent where more or less abandoned as native types.

Abandonded? They were specifically reserved for being used for 128-bit signed and unsigned types at an indeterminate point in the future. Nothing was abandonded, but nothing has been needed either, so it hasn't been implemented.

> But would it be possible to have Cent/UCent as library types?
> 
> We have Complex, and Walter recently proposed the HalfFloat type.
> 
> Why not Cent and UCent?
> 
> Is it too complex for library code? I'd suspect you need to catch overflow flags for efficient carry over, but D has built-in asm, so that shouldn't be too complicated... Should it?
> 
> Or do we already have some sort of generic (statically sized) big
> inter, eg:
> Big!128 or UBig!128? Or if not, would we want that?
> 
> Should I open an ER for either of the two ideas?

I'd argue for sticking to BigInt if you want big numbers rather than adding the complication of adding a Cent and UCent library type. To get them right, you need a fair bit of what BigInt has anyway. What gain is there in having Cent or UCent over just using BigInt? I could see benefit in 128 bit built-in types, but I don't see what the point is of library types for them, not when we already have BigInt.

- Jonathan M Davis

On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis wrote:
> but I don't see what the point is of library types for them, not when we already have BigInt.

 Fixed sizes means no GC/allocation for passing the data around to functions; And optimized assembly code. Beyond that, it doesn't seem highly important. But if it's around as a viable option people will begin using it.

 You never know when/where you could need it.

On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis wrote:
> On Monday, December 31, 2012 19:56:11 monarch_dodra wrote:
>> I'm asking this as a end user:
>> 
>> It was my understanding that cent/ucent where more or less
>> abandoned as native types.
>
> Abandonded? They were specifically reserved for being used for 128-bit signed
> and unsigned types at an indeterminate point in the future. Nothing was
> abandonded, but nothing has been needed either, so it hasn't been implemented.
>
> [SNIP]
>
> - Jonathan M Davis

I remember reading somewhere that they would never be implemented, but that cent/ucent was still forbidden keyword, to avoid any confusion.

My bad then I guess.

On Monday, December 31, 2012 21:11:13 monarch_dodra wrote:
> I remember reading somewhere that they would never be implemented, but that cent/ucent was still forbidden keyword, to avoid any confusion.
> 
> My bad then I guess.

They won't ever be implemented for D1, since D1 will be unsupported following the next release, which may be where you heard that. For D2, it's a question of when Walter thinks that they're worth implementing, and AFAIK, there is no current plan as to when that would be (particularly since there are no 128-bit x86 systems on the horizon). It's definitely not the case though that it was decided that they would never be implemented for D2.

- Jonathan m Davis

On Monday, December 31, 2012 20:24:42 Era Scarecrow wrote:
> On Monday, 31 December 2012 at 19:10:09 UTC, Jonathan M Davis
> 
> wrote:
> > but I don't see what the point is of library types for them, not when we already have BigInt.
> 
>   Fixed sizes means no GC/allocation for passing the data around
> to functions; And optimized assembly code. Beyond that, it
> doesn't seem highly important. But if it's around as a viable
> option people will begin using it.
> 
>   You never know when/where you could need it.

Given that we already have cent and ucent reserved specifically for 128-bit integral types, I think that Cent and UCent only make sense if we have an urgent use case that needs 128-bit integral types where BigInt won't work, and we need a big reason not to just implement cent and ucent. Otherwise, why not just implement cent and ucent? Long term, Cent and UCent just don't make sense.

If someone wants to implement them for themselves, fine. But since the plan is presumably to implement cent and ucent eventually, why put them in the standard library where they've effectively given themselves an expiration date? Especially when it's likely to be a rather niche need in the first place?

- Jonathan M Davis