Policy for exposing range structs

[Anon via Digitalmars-d]

On Thursday, 31 March 2016 at 17:52:43 UTC, Adam D. Ruppe wrote:
> Yeah, but my thought is the typical use case isn't actually the 
> problem - it is OK as it is. Longer strings are where it gets 
> concerning to me.

Doubling the size of UTF-8 (the effect of the current base16 
encoding) bothers me regardless of string length. Especially when 
use of __MODULE__ and/or __FILE__ as template arguments seems to 
be fairly common.

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.

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()`. However, that compile time string processing is much 
better served with a CTFE-able function using a Rope for 
manipulating the string until it is finalized into a normal 
string. If you are doing compile-time string manipulation with 
templates, the big symbol is the least of your worries. The 
repeated allocation and reallocation will quickly make your code 
uncompilable due to soaring RAM usage. The same is (was?) true of 
non-rope CTFE string manipulation. Adding a relatively 
memory-intensive operation like compression isn't going to help 
in that case.

Granted, the language shouldn't have a cut-off for string length 
in template arguments, but if you load a huge string as a 
template argument, I think something has gone wrong in your code. 
Catering to that seems to me to be encouraging it, despite the 
existence of much better approaches.

The only other case I can think of where you might want a large 
string as a template argument is something like:

```
struct Foo(string s)
{
     mixin(s);
}

Foo!q{...} foo;
```

But that is much better served as something like:

```
mixin template Q()
{
     mixin(q{...}); // String doesn't end up in mangled name
}

struct Foo(alias A)
{
     mixin A;
}

Foo!Q foo;
```

Or better yet (when possible):

```
mixin template Q()
{
     ... // No string mixin needed
}

struct Foo(alias A)
{
     mixin A;
}

Foo!Q foo;
```

The original mangling discussion started from the need to either 
fix a mangling problem or officially discourage Voldemort types. 
Most of the ideas we've been discussing and/or working on have 
been toward keeping Voldemort types, since many here want them. 
I'm not sure what use case would actually motivate compressing 
strings/symbols.

My motivations for bootstring encoding:

* Mostly care about opDispatch, and use of __FILE__/__MODULE__ as 
compile-time parameters. Symbol bloat from their use isn't 
severe, but it could be better.
* ~50% of the current mangling size for template string parameters
* Plain C identifier strings (so, most identifiers) will end up 
directly readable in the mangled name even without a demangler
* Retains current ability to access D symbols from C (in contrast 
to ideas that would use characters like '$' or '?')
* I already needed bootstring encoding for an unrelated project, 
and figured I could offer to share it with D, since it seems like 
it would fit here, too