On Fri, Jan 18, 2019 at 08:03:48PM +0000, Mark via Digitalmars-d-announce wrote: [...]
> Why not do away with AliasSeq and use strings all the way?
> 
> string Constify(string type)
> {
>     // can add input checks here
>     return "const(" ~ type ~ ")";
> }
> 
> void main()
> {
>     import std.algorithm : map;
>     enum someTypes = ["int", "char", "bool"];
>     enum constTypes = map!Constify(someTypes);
>     mixin(constTypes[0] ~ "myConstInt = 42;"); // int myConstInt = 42;
> }
> 
> Represent types as strings, CTFE them as you see fit, and output a string that can then be mixin'ed to use the actual type. :)

That would work, but it would also suffer from all the same problems as macro-based programming in C.  The compiler would be unable to detect when you accidentally pasted type names together where you intended to be separate, the strings may not actually represent real types, and generating code from pasting / manipulating strings is very error-prone. And you could write very unmaintainable code like pasting partial tokens together as strings, etc., which makes it hard for anyone else (including yourself after 3 months) to understand just what the code is trying to do.

Generally, you want some level of syntactic / semantic enforcement by the compiler when you manipulate lists (or whatever other structures) of types.


T

-- 
INTEL = Only half of "intelligence".

On 2019-01-18 20:28, Stefan Koch wrote:

> The only difference that type-functions have from what you describe is that it does not need to occupy a keyword 'type'.

You're using "alias" instead of my "type" keyword?

-- 
/Jacob Carlborg

On Friday, 18 January 2019 at 20:32:35 UTC, Jacob Carlborg wrote:
> On 2019-01-18 20:28, Stefan Koch wrote:
>
>> The only difference that type-functions have from what you describe is that it does not need to occupy a keyword 'type'.
>
> You're using "alias" instead of my "type" keyword?

yes. After all what type-functions do when returning types,  is to return an alias.
Since it's unable to create types this is all it can do.

On Friday, 18 January 2019 at 20:03:48 UTC, Mark wrote:
> [...]
>
> Represent types as strings, CTFE them as you see fit, and output a string that can then be mixin'ed to use the actual type. :)

Two problems:

1) Mixing in a string is unhygienic. If two modules (or two scopes in the same module) define types with the same name, you might get the wrong one.

2) You can't mixin the name of a Voldemort type.

On Friday, 18 January 2019 at 20:29:08 UTC, H. S. Teoh wrote:
> That would work, but it would also suffer from all the same problems as macro-based programming in C.  The compiler would be unable to detect when you accidentally pasted type names together where you intended to be separate, the strings may not actually represent real types, and generating code from pasting / manipulating strings is very error-prone. And you could write very unmaintainable code like pasting partial tokens together as strings, etc., which makes it hard for anyone else (including yourself after 3 months) to understand just what the code is trying to do.
>
> Generally, you want some level of syntactic / semantic enforcement by the compiler when you manipulate lists (or whatever other structures) of types.
>
>
> T

Well, it's the approach Andrei laid out in his DConf 2018 talk:
https://youtu.be/-0jcE9B5kjs?t=2641

The advantage is how simple it is, and that it only uses existing language constructs. But, indeed, the problems you mention are not insignificant.