digitalmars.D.bugs - [Issue 785] New: static if(is(cent)): "basic type expected, not cent"
- d-bugmail puremagic.com Jan 02 2007
- d-bugmail puremagic.com Feb 02 2007
- d-bugmail puremagic.com Mar 21 2007
- d-bugmail puremagic.com Oct 28 2007
- d-bugmail puremagic.com Oct 29 2007
- d-bugmail puremagic.com Sep 08 2009
- d-bugmail puremagic.com Sep 09 2009
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
d-bugmail puremagic.com 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
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
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
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
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
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