Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
Hello, I'm generating code using mixins and one of my mixins expands to something like this: ``` adder(MyType!MyEnum.INTEGER(), MyType!MyEnum.STRING()); ``` `MyType!MyEnum.STRING` is generated with `T.stringof `. I get the error: ``` Error: template instance `MyType!(MyEnum)` does not matc

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Monday, 27 December 2021 at 21:05:51 UTC, data pulverizer wrote: Hello, ... ... an equivalent mixin error would be ``` //... alias DOUBLE = MyEnum.DOUBLE; alias STRING = MyEnum.STRING; alias INTEGER = MyEnum.INTEGER; void main() { alias T = MyType!(INTEGER); alias U = MyType!(STRING)

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread Adam Ruppe via Digitalmars-d-learn
On Monday, 27 December 2021 at 21:05:51 UTC, data pulverizer wrote: adder(MyType!MyEnum.INTEGER(), MyType!MyEnum.STRING()); The rule for !(args) is of you leave the parenthesis off, it only uses the next single token as the argument. So it will never include a dot; it is like you wrote `MyTyp

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Monday, 27 December 2021 at 21:31:03 UTC, Adam Ruppe wrote: if you can paste teh code where you generate this I can prolly show you a much easier way to do it. stringof sucks really hard. Will the above `mixin` example suffice? It expands to the code that I described.

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Monday, 27 December 2021 at 21:31:03 UTC, Adam Ruppe wrote: if you can paste teh code where you generate this I can prolly show you a much easier way to do it. stringof sucks really hard. I think the only thing to do for now is probably for me to construct a template that creates a proper s

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Monday, 27 December 2021 at 22:52:58 UTC, data pulverizer wrote: I think the only thing to do for now is probably for me to construct a template that creates a proper string for this type. It would look something like this: ``` enum safe_stringof(T) = T.stringof; template safe_stringof(T: M

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread Adam Ruppe via Digitalmars-d-learn
On Monday, 27 December 2021 at 21:21:30 UTC, data pulverizer wrote: alias T = MyType!(INTEGER); What is MyType? enum code = "writeln(\"instance: \", adder(" ~ T.stringof ~ "(), " ~ U.stringof ~ "()" ~ "));"; And why is this a string mixin instead of a plain simple function

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Monday, 27 December 2021 at 23:04:40 UTC, Adam Ruppe wrote: On Monday, 27 December 2021 at 21:21:30 UTC, data pulverizer wrote: alias T = MyType!(INTEGER); What is MyType? enum code = "writeln(\"instance: \", adder(" ~ T.stringof ~ "(), " ~ U.stringof ~ "()" ~ "));"; A

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 28 December 2021 at 00:13:13 UTC, data pulverizer wrote: The types I'm generating are a template type I've constructed for R's SEXP, so that my wrapped numeric vector (struct) type is denoted `RVector!(REALSXP)`. But `alias REALSXP = SEXPTYPE.REALSXP` where `SEXPTYPE` is an `enum`.

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread Adam Ruppe via Digitalmars-d-learn
On Tuesday, 28 December 2021 at 00:13:13 UTC, data pulverizer wrote: There are various requirements, sometimes I have to cast or type convert, so I **need** the type to paste correctly and explicitly. You almost never actually need types as strings. I'm almost certain there's a better way for

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Tuesday, 28 December 2021 at 00:32:03 UTC, Paul Backus wrote: The result of `.stringof` is completely implementation-defined, may change arbitrarily between compiler releases, and is not even guaranteed to be valid D code in the first place. Wow, I didn't know this. In this case, the simpl

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread Paul Backus via Digitalmars-d-learn
On Tuesday, 28 December 2021 at 00:42:18 UTC, data pulverizer wrote: On Tuesday, 28 December 2021 at 00:32:03 UTC, Paul Backus wrote: In this case, the simplest solution is to have your code generator accept a string as its input, rather than a type. For example: ```d enum instantiate(string

Re: Ambiguity issue with expanding and evaluating single template type parameter enums

2021-12-27 Thread data pulverizer via Digitalmars-d-learn
On Tuesday, 28 December 2021 at 00:57:27 UTC, Paul Backus wrote: ```d enum instantiate(string type, string expr) = type ~ "(" ~ expr ~ ")"; pragma(msg, instantiate!("RVector!(SEXPTYPE.REALSXP)", "x")); ``` One possibility is to generate a collection of compile time strings that denote the