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)){
# }
#


-- 

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.


-- 

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?


-- 

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.


-- 

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.


-- 

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: -------

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: -------

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: -------

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: -------

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: -------