www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 785] New: static if(is(cent)): "basic type expected, not cent"

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785

           Summary: static if(is(cent)): "basic type expected, not cent"
           Product: D
           Version: 0.178
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: thomas-dloop kuehne.cn


cent is a not-yet-implemented basic type but DMD fails to compile the code 
below below with the error message:  basic type expected, not cent

#
# static if(is(cent)){
# }
#


--
Jan 02 2007
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




------- Comment #1 from bugzilla digitalmars.com  2007-02-02 21:29 -------
Since cent and ucent are not implemented, they should produce error messages.


--
Feb 02 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |




------- Comment #2 from smjg iname.com  2007-03-21 12:34 -------
That a type isn't implemented shouldn't render code that tries to use it
_syntactically_ invalid.  It should be rejected at the semantic level, just as
it would be if it were just another undefined identifier.  Thus the body of the
static if would simply be conditioned out, because cent is not a valid type.

How else is one supposed to test whether a given compiler has cent/ucent
implemented?


--
Mar 21 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


bugzilla digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID




------- Comment #3 from bugzilla digitalmars.com  2007-10-28 22:21 -------
If it isn't implemented, it doesn't really matter at what point in the
compilation process it isn't implemented. To check if it is implemented, I
suggest going by the version number in std.compiler, or defining your own
version identifier for it.

cent/ucent keywords are reserved simply to prevent anyone from using them as
variable names, so that they *can* be used in the future.


--
Oct 28 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|static if(is(cent)): "basic |Make 'cent' and 'ucent'
                   |type expected, not cent"    |syntactically valid pending
                   |                            |implementation




------- Comment #4 from smjg iname.com  2007-10-29 06:36 -------
That doesn't follow.  Because the token is syntactically illegal at the moment,
and because versioned out code still has to be syntactically valid, that won't
work.  Though you could use a mixin to get around the difficulty, this is a
rather dirty workaround.  It would be silly if library code that wants to use
cent if it's implemented has to either be peppered with such mixins or define
its own alias and check if that exists instead.

Besides, how is one supposed to know in which (DM)D version cent/ucent will be
implemented?  Similarly, with the number of different version identifiers
people are likely to make up, they can't all coincide with the one that you
decide to use.  And even if any time now you decide on a version identifier
(such as D_Cent) that is going to denote support for this feature, it is a much
neater solution if is(cent) or is(ucent) is defined to do the same, and
attempts to use cent/ucent rejected at the semantic, not syntactic, level.

Meanwhile, I'm changing this to an enhancement request.

And it should be straightforward to implement.  Effectively, cent and ucent
would parse as BasicType, but the semantic analysis would treat them as the
_identifiers_ 'cent' and 'ucent', which are always undefined because they
cannot be used in declarations, where the _syntax_ requires an Identifier.


--
Oct 29 2007
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #5 from Jeremie Pelletier <jeremiep gmail.com> 2009-09-08 17:04:01
PDT ---
Created an attachment (id=447)
Basic frontend support for cent/ucent.

I've attached a simple patch which implements basic support for cent/ucent to
the dmd frontend. It passes all semantic levels and throw a not implemented
error if sent to the backend. This allow its use in semantic contexts that do
not generate code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 08 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #6 from Stewart Gordon <smjg iname.com> 2009-09-09 01:08:15 PDT ---
(In reply to comment #5)

 Created an attachment (id=447) [details]
 Basic frontend support for cent/ucent.
 
 I've attached a simple patch which implements basic support for cent/ucent to
 the dmd frontend. It passes all semantic levels and throw a not implemented
 error if sent to the backend. This allow its use in semantic contexts that do
 not generate code.


Do is(cent) and is(ucent) correctly (for the time being) evaluate to false when
your patch is applied?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #7 from Jonathan M Davis <jmdavisProg gmx.com> 2012-01-31 10:10:02
PST ---
I agree with Walter on this one. cent and ucent are merely keywords in
preparation for if/when we decide to add 128-bit integer types to the language.
Keywords are plenty for that. I see no reason to expect any code written with
them to work on any level or why anyone would think that writing code now with
cent or ucent with the idea that it will work later makes sense. AFAIK, it's
never been promised that cent and ucent would _ever_ be added as types. It's
just that the keywords have been reserved in order to future proof the
language.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #8 from Andrei Alexandrescu <andrei metalanguage.com> 2012-01-31
10:43:43 PST ---
The feature is not implemented, and the simple patch does too little to help in
that direction. Please let's leave this closed, this future direction doesn't
belong to bugzilla. Thanks.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #9 from Stewart Gordon <smjg iname.com> 2012-01-31 16:05:30 PST ---
(In reply to comment #7)

 I agree with Walter on this one.  cent and ucent are merely 
 keywords in preparation for if/when we decide to add 128-bit 
 integer types to the language.  Keywords are plenty for that.  I 
 see no reason to expect any code written with them to work on any 
 level.


The point of doing this is to enable libraries to support cent/ucent _if_ the
language/compiler/platform supports it, by using a static if to test whether
the type exists.


 or why anyone would think that writing code now with cent or ucent 
 with the idea that it will work later makes sense.


For many library features, it makes sense to support operations on all of the
integer types, for example:
- construction of a bigint or bit array from an integer or array thereof
- conversion of a bigint or a bit array to an array of integers
- file I/O and communications

Why shouldn't someone who implements the same feature for for byte, ubyte,
short, ushort, int, uint, long and ulong be allowed to implement it for cent
and ucent as well while at it?

Moreover, if we decide to support it only on those platforms that natively
implement it, or support it on those platforms before implementing it for those
that don't, why should library writers be prevented from supporting it by the
requirement for the library to work on those platforms that don't have 128-bit
integer arithmetic built in?

Or are you suggesting that all the use cases are covered by templates?

(In reply to comment #8)

 The feature is not implemented, and the simple patch does too 
 little to help in that direction.


That's like refusing to add an autosave feature to an app because it does too
little to help stop the program crashing.

(In reply to comment #8)

 Please let's leave this closed, this future direction doesn't 
 belong to bugzilla.  Thanks.


What do you mean by this?  I thought that we were all agreed by now that
enhancement requests are welcome here.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #10 from Andrei Alexandrescu <andrei metalanguage.com> 2012-01-31
16:26:16 PST ---
(In reply to comment #9)

 (In reply to comment #8)

 The feature is not implemented, and the simple patch does too 
 little to help in that direction.


 
 That's like refusing to add an autosave feature to an app because it does too
 little to help stop the program crashing.


I fail to derive much from this comparison, sorry.


 (In reply to comment #8)

 Please let's leave this closed, this future direction doesn't 
 belong to bugzilla.  Thanks.


 
 What do you mean by this?  I thought that we were all agreed by now that
 enhancement requests are welcome here.


This is not an enhancement request. It is a possible future feature that we are
well aware of, will not be forgotten, and should be present in a longer-term
document (as opposed to here). Let's leave this closed and focus on more
workable action items. Thanks!

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #11 from Stewart Gordon <smjg iname.com> 2012-01-31 16:52:39 PST ---
(In reply to comment #10)

 This is not an enhancement request.


I still don't understand that statement in the slightest.


 It is a possible future feature that we are well aware of, will not 
 be forgotten, and should be present in a longer-term document


True.  But in a longer-term document for what purpose?  To be a record of
someone having requested an improvement that will never be implemented?


 (as opposed to here).


If a D user wants a given feature/improvement, it's perfectly reasonable of
them to post it here, at least in my understanding.  Whether the people in
charge are going to implement or not is another matter - it's half the purpose
of resolutions, not of arguing over whether it should ever have been filed here
in the first place.


 Let's leave this closed and focus on more workable action items.  
 Thanks!


OK.  But please note that Walter himself hasn't commented on this in over 4
years now.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #12 from Walter Bright <bugzilla digitalmars.com> 2012-01-31
16:54:48 PST ---

The point of doing this is to enable libraries to support cent/ucent _if_ the


language/compiler/platform supports it, by using a static if to test whether
the type exists.

You can do something like:

   static if (__traits(compiles, { ucent a = 3; })) ...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #13 from Andrei Alexandrescu <andrei metalanguage.com> 2012-01-31
16:59:24 PST ---
(In reply to comment #11)

 (In reply to comment #10)

 This is not an enhancement request.


 
 I still don't understand that statement in the slightest.


Sorry, I only now see how that might be confusing. I was referring to
"implement cent/ucent", as opposed to this particular patch.


 Let's leave this closed and focus on more workable action items.  
 Thanks!


 
 OK.  But please note that Walter himself hasn't commented on this in over 4
 years now.


Thanks for your understanding.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #14 from Stewart Gordon <smjg iname.com> 2012-01-31 17:29:40 PST ---
(In reply to comment #12)

The point of doing this is to enable libraries to support cent/ucent _if_ the


 language/compiler/platform supports it, by using a static if to test whether
 the type exists.
 
 You can do something like:
 
    static if (__traits(compiles, { ucent a = 3; })) ...


Under DMD 2.057 with the most trivial use:

static if (__traits(compiles, { ucent a = 3; })) {}

cent_compiles.d(1): found 'ucent' instead of statement

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |yebblies gmail.com
         Resolution|WONTFIX                     |


--- Comment #15 from yebblies <yebblies gmail.com> 2012-02-01 14:14:35 EST ---
I actually think this is something worth asking for.
I intend to have a go at implementing cent and ucent once I understand more of
the backend code, so it hopefully isn't too far off.

The following code gives _parsing_ errors, which doesn't make a lot of sense.

version(none) cent x;
static if (is(cent)) {}
static if (__traits(compiles, { cent x; }))

If this was like macro, and we didn't know what cent/ucent support might
eventually look like, then it would make sense to reject it that early.  But we
know cent/ucent will behave exactly like the rest of the built in integer
types.

The solution is trivial:

https://github.com/yebblies/dmd/commit/52028d5b0995744b8241e6c27c6fc1ea894ee3e6

Please take a look and tell me what we lose by adding this to the language.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #16 from Walter Bright <bugzilla digitalmars.com> 2012-01-31
19:20:29 PST ---
Not bad, but they should be in TypeBasic.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #17 from yebblies <yebblies gmail.com> 2012-02-01 14:26:05 EST ---
(In reply to comment #16)

 Not bad, but they should be in TypeBasic.


I know, but TypeBasic doesn't have a custom semantic routine and has no support
for 128bit types, so I don't want to mix it in with that code yet.

Is this something you would consider a blocker to merging the patch?  If so
I'll have a go at integrating it with TypeBasic.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #18 from Walter Bright <bugzilla digitalmars.com> 2012-01-31
19:53:30 PST ---
Yes, it would be a blocker.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
            Version|D1                          |D1 & D2
         AssignedTo|bugzilla digitalmars.com    |yebblies gmail.com


--- Comment #19 from yebblies <yebblies gmail.com> 2012-02-01 15:52:52 EST ---
Ok.  Redone as TypeBasic - easier than I expected.

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

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #20 from Andrei Alexandrescu <andrei metalanguage.com> 2012-02-01
00:58:00 PST ---
Focus, that's what we lose.

1. There's no real request for cent and ucent.

2. This "let's add a filler doing nothing, discuss it ad nauseam, and consider
implement later" is an utter waste of time. If someone really wants they can
implement it, don't add this useless filler for hypothetical future-proof
libraries that don't exist. This breaks a lot of good principles so badly it
hurts.

3. We're better off implementing FixedInt!size for large integers of
statically-allocated size. Granted, those don't benefit of all possible
optimizations but there's more flexibility.

Please close this and let's leave it closed. Thanks much.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #21 from yebblies <yebblies gmail.com> 2012-02-01 20:12:24 EST ---
With respect, Andrei, it's my time to waste.

A lot more time has been wasted on arguing about it than the 5 minutes it took
for me to make a patch that fixed it.

128 bit integer types have been considered possible enough for D that keywords
were reserved for them.  I fully intend to see them implemented if possible.

It seems lately you're frustrated that development effort isn't always directed
where you want it, but this is unavoidable in open source projects - people
will work on what they want to work on.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #22 from Andrei Alexandrescu <andrei metalanguage.com> 2012-02-01
01:17:09 PST ---
It's great you want to work on this. It's this particular patch that I have
difficulty backing: it future proofs code that doesn't exist, for a feature
that doesn't exist either, on account of an assumed need. No matter how I frame
it it doesn't make any sense.

No response needed - proceed as you wish.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #23 from Stewart Gordon <smjg iname.com> 2012-02-01 04:21:17 PST ---
(In reply to comment #20)

 2. This "let's add a filler doing nothing, discuss it ad nauseam, and consider
 implement later" is an utter waste of time. If someone really wants they can
 implement it, don't add this useless filler for hypothetical future-proof
 libraries that don't exist.


So you're waiting for somebody to write a library, built on my first point in
comment 9, that doesn't compile because current DMD flags a syntax error?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #24 from Stewart Gordon <smjg iname.com> 2012-02-01 04:36:09 PST ---
Moreover, when we finally get the types, there will still be users on older
compilers (DM or third-party, possibly commercial), even some on platforms for
which an up-to-date compiler is not yet available, who can't compile other
people's code because it uses syntax that is still illegal in the version they
have.  The sooner this issue is dealt with, the less risk of this happening.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #25 from yebblies <yebblies gmail.com> 2012-02-01 23:44:50 EST ---
(In reply to comment #24)

 Moreover, when we finally get the types, there will still be users on older
 compilers (DM or third-party, possibly commercial), even some on platforms for
 which an up-to-date compiler is not yet available, who can't compile other
 people's code because it uses syntax that is still illegal in the version they
 have.  The sooner this issue is dealt with, the less risk of this happening.


This is unlikely to ever be a problem.  D2 compilers break enough code (wrong
or not) between versions that using one a couple of releases old probably won't
compile your code anyway.  Of course, this will hopefully change in the future.

The bigger issue that makes this less of a waste of time is that D compiler
with different backends, or running on different backends, may choose not to
implement cent/ucent, and if they do this in the parser then the code will be
non-portable.  The proposed patch is a much more correct solution to this
problem.

Regardless, there is a patch for this issue already out there which is waiting
for review.  I don't think discussing it further at this point will achieve
anything.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 01 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Witold Baryluk <baryluk smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk smp.if.uj.edu.pl


--- Comment #26 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2012-02-03
01:01:05 PST ---
Hi,

I was waiting for support of this mainly to write generic and more future proof
library. As stated I cannot even try conditional compilation using cent/ucent
now. Also some platforms allows doing 64bit * 64bit -> full 128bit product, so
it could be possible represented in the future as u/cent, which can have some
basic arithmetic imlemented (like bitshifting, extracing upper/lower 64-bits).
I'm also starting to do some research on FPGAs (with D!) and was wondering if
FPGA can augment some functions to main CPU, to add biger arithmetic on demand.
Would be good to have this as transparent as possible, so at least I can do:


    static if(is(cent)){
         ...
    }

in my library, or something very similar.

Also it would be good to have in Phobos, a something similar to existing
BigInt, but to behave more like normal arithmetic in terms of overflows and
integer promotions. For example WideUInt!(32) will be equivalent to uint,
WideUInt!(128) will be equivalent to ucent, or emulated using 2xulong, but
WideUInt!(256) will probably by just something like BigInt, but with truncation
or results (so multiplication, substraction or addition, powers, like
WideUInt!(256) *  WideUInt!(256) will return always  WideUInt!(256), never less
or more). It sometimes may be wastefull (when value is actually small), but is
usefull especially in cryptography (when one wants to treat this 32-bytes of
memory as unsigned integer, and also want to be sure time of operation is
constant independend of the range or value of operands), like hash, symetric or
asymetric encryption. It just makes it easier to use general WideUInt template,
which will use hardware support or fallback to the software. Addition and
bitwise logic can be easly translated to the SIMD and potential loops
statically unrolled at compile time. Also things like multiplication emulation
in such software can be done faster, even for big sizes, because library can
determine which algorithm (simple, Karatsuba, FFT) is best for particular width
at compile time (it also make it possible to depend this choice on size of left
and right operand), statically without any runtime checks (big win). Similary
for Karatsuba and FFT, optimal structure of recurences can be calculated at
compile time by library, removing many conditionals for runtime code and
allowing agressive inlineing. I know many of this things can be solved by good
JIT compiler and VM (like HotSpot - by specializing code and loops based on
runtime constants, and then agressivly optimizing it including unrolling,
vectorizing and inlineing calls), but I like to relay more on deterministic
behaviour of compiler and statically do as much as possible at compile time.

Is this something a Phobos would like to have? Cryptographer will probably
would like to implement own one even if Phobos provides such functionality
because I guess Phobos will aim at maximum performance, but Cryptographers will
aim at security and lack of side-channel attacks, and this may be contradicting
aims (however Crypgrapher can use Phobos WideUInt!(K), and implement own fast
and safe powmod(a,b,n), with n=2^K (const, so rather powmod!(K)(a,b)). I think
given existing BigInt presence in Phobos it should be relativly easy to add
WideInt/WideUInt.

When we are at long types, I have another question/problem about language.

I was wondering if in case of float with quad-preceission, one should use
'real' keyword or something else? I think we should add quadprecision floats
(+complex ones) as possibility to the language, to the existing float, and
double, for three reasons: they are commonly used in PowerPC (long double,
probably not in hardware, but done by most compilers in software), there are
some speculations about hardware support for them, and they can be cheply
emulated in software using double-double scheme (which isn't exactly equivalent
to 128-bit IEEE-754 arithmetic, but have guaranted 107-bits of precision
compared to 113-bits of precisions in IEEE-754 quad precision, range is also
limited to about 10^308, instead of 10^4932, but this is not a practical
limitation in any real application). Some SPARC ISA have reserved bits for quad
precission in FPU, also I know on PowerPC some C/Fortran compiler interpretes
'long double' as quad precission, but actually does double-double calculations.
Same does probably Sun Studio Compiler on SPARC. I also know that Intel
compiler FORTRAN and C does this on Itanium. So one can argue that there is
almost no hardware support for quad precission, so this should be leaved in
library, using structs and software implementation. But as reality also shows
there is demand for quad precission. On the other hand, somebody can say that
it is easly possible to syntethize such hardware in FPGA copouled with CPU
(ARM) on demand. Just was going to ask, theoretically if some compiler (most
probably modified LDC + own LLVM backend) would want to support quad
precission, do it need to use new keyword (sic!), like 'quad' and 'cquad', or
just use 'real' and 'creal' ?

Sorry for messing with bug report, but was thinking this is discussion is
essentially equivalent to 'cent' discussion - future proofing language and
libraries.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #27 from Witold Baryluk <baryluk smp.if.uj.edu.pl> 2012-02-03
01:09:31 PST ---
Just to add some additional context.

I think many CUDA and OpenCL compilers, as well some tools which uses
OpenGL/Cg, whetever, when asked to do double calculations actually uses
float-float (2x single precission) to have almost same precission of double (49
bits compared to 52 bit of mantisa, which is big win compared to 23 bigs of
single precission floats). So it is common to use float-float or double-double
schemes actually to boost precission. I know software and library will need
much more testing by developer to make sure lack of IEEE-754 comppilance is not
a problem in given library or application, but I think D should in theory allow
some compiler to diverge from IEEE-754 compilance if user really wants to.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 03 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


ponce <aliloko gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aliloko gmail.com


--- Comment #28 from ponce <aliloko gmail.com> 2012-04-23 13:15:23 PDT ---
I have a mostly working software implementation for cent and ucent.
https://github.com/p0nce/gfm/blob/master/math/softcent.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 23 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #29 from github-bugzilla puremagic.com 2012-10-28 06:49:27 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/2e70bcac262e879769f3236a05ce9bc46483a429
Issue 785 - Make 'cent' and 'ucent' syntactically valid pending implementation

This adds just enough of cent and ucent to parse, but fail at the semantic
stage.  This allows cent and ucent to be used inside version and static if
blocks.

https://github.com/D-Programming-Language/dmd/commit/effb4c0885c90158807aa2de98aab0ff92c69a37
Merge pull request #672 from yebblies/issue785

Issue 785 - Make 'cent' and 'ucent' syntactically valid pending implementation

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 28 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Kenji Hara <k.hara.pg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D1 & D2                     |D1


--- Comment #30 from Kenji Hara <k.hara.pg gmail.com> 2012-10-28 07:17:07 PDT
---
Fixed in D2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 28 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
            Version|D1                          |D2
         Resolution|                            |FIXED
            Summary|(D1 only) Make 'cent' and   |Make 'cent' and 'ucent'
                   |'ucent' syntactically valid |syntactically valid pending
                   |pending implementation      |implementation


--- Comment #31 from Don <clugdbug yahoo.com.au> 2012-11-12 23:49:29 PST ---
Closing since fixed on D2. Doesn't make sense for D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 12 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #32 from Stewart Gordon <smjg iname.com> 2012-11-13 05:14:49 PST ---
(In reply to comment #31)

 Closing since fixed on D2. Doesn't make sense for D1.


How do you mean???

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 13 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #33 from Jonathan M Davis <jmdavisProg gmx.com> 2012-11-21 01:03:00
PST ---

 Closing since fixed on D2. Doesn't make sense for D1.





How do you mean???


As of the end of this year, D1 will no longer be supported, so it will
definitely never have cent or ucent unless someone forks it and continues to
work on it, in which case, they can do whatever they want with it. But the
official D1 compiler will never have cent or ucent, so there's no reason to
worry about them for D1.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|D2                          |D1 & D2


--- Comment #34 from Stewart Gordon <smjg iname.com> 2012-11-21 15:29:46 PST ---
(In reply to comment #33)

 Closing since fixed on D2. Doesn't make sense for D1.




 

How do you mean???


 
 As of the end of this year, D1 will no longer be supported, so it will
 definitely never have cent or ucent unless someone forks it and continues to
 work on it, in which case, they can do whatever they want with it. But the
 official D1 compiler will never have cent or ucent, so there's no reason to
 worry about them for D1.


That's exactly why it makes no sense that D1 reserves the words at all.  So it
certainly isn't a D2-only issue.  Still, maybe it isn't worth reopening it
since D1 is about to be abandoned.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 21 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=785



--- Comment #35 from Jonathan M Davis <jmdavisProg gmx.com> 2012-11-21 15:43:33
PST ---

 That's exactly why it makes no sense that D1 reserves the words at all. So it
 certainly isn't a D2-only issue.  Still, maybe it isn't worth reopening it
 since D1 is about to be abandoned.


Yes, it's generally not to reserve identifiers which will never be used, but
other languages have done it. For instance, Java reserves goto and const and
never uses them. So, it's really not that big a deal if D1 reserves words that
it never uses.

D1 is merely a fork/branch of D from a point where it was reasonably stable and
Walter was about to introduce some major, breaking changes, and it was decided
that it would be kinder to the existing D users at the time to branch for
continued development. It was never really meant to stick around long term. And
it's about to be officially unsupported. So, it's not all that surprising if it
has some rough edges anyway. And all that this means is that there are two
words that no one using D1 can use - cent and ucent. That's far from a disaster
and really not worth our time to worry about IMHO. Also note that it's one of
D1's biggest users - Don - who closed the bug. If Don doesn't think that it
needs to be fixed for D1, then I think that it's safe to say that we don't need
to worry about it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 21 2012