Policy for exposing range structs

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 31 March 2016 at 20:12:34 UTC, Anon wrote:
> Having thought about it a bit more, I am now of the opinion 
> that super-long strings have no business being in template 
> args, so we shouldn't cater to them.

meh, if it is allowed, it is going to happen. Why make it worse 
when there's so little cost in making it better?

> The main case with longer strings going into template arguments 
> I'm aware of is for when strings will be processed, then fed to 
> `mixin()`.

I often don't actually modify the string at all and by putting 
the string as a template argument, it enables a kind of 
compile-time memoization like I talked about here a short while 
ago: http://stackoverflow.com/a/36251271/1457000

The string may be exceedingly if imported from a file or 
generated externally and cached:

MyType!(import("definition.txt")) foo;

enum foo = ctfeFunction();

MyType!foo test;


I've never had a huge problem with this in practice, but I've 
never had a huge problem with big names in practice at all 
either. I can imagine both though.

(what bothers me more than the mangle actually is the compiler 
error messages showing all those strings. Gross. I'd like to see 
XML error messages to make displaying them easier. But that's a 
separate topic.)

> The original mangling discussion started from the need to 
> either fix a mangling problem or officially discourage 
> Voldemort types.


Yes, indeed, that's probably the bigger problem.

> * Retains current ability to access D symbols from C (in 
> contrast to ideas that would use characters like '$' or '?')

$ is actually a valid identifier character in C (and quite a few 
other languages). You can use it in the linker as well as in C 
source code.