std.format and uninitialized elements in CTFE

[Steven Schveighoffer]

On 12/9/19 1:10 AM, berni44 wrote:

> So, what would we expect? Ideally, it would note, that it's not a good 
> idea to make a range const. But I think, that neither the compiler (does 
> not know about ranges) nor Phobos (may not even be called) can do that.
> 
> Yet I've got no clue, what's best here...

This is a frequent problem when building generic "do the best you can" 
libraries.

Those libraries usually go something like this:

static if(someFeatureWorks!T)
{
    useFeature(t);
}
else
{
    fallback(t);
}

Generally the "someFeatureWorks" (e.g. isRange) works on the assumption 
that you can compile something. The problem is, that there are various 
cases why you can't compile it, not all of which mean it wasn't 
*intended* to compile. For example, having an error in one of your 
functions makes it all of a sudden not a range!

One thing we could do (well, actually, we can't do this because it would 
be too disruptive) is change the check that you can compile a call to 
popFront into hasMember!(T, "popFront"). What this does is capture the 
intention -- if the user put in a popFront method, I can't imagine they 
wanted to declare anything but a range type.

Then the code tries to use it as a range and it fails because you didn't 
do something correctly (i.e., you made it const, or you have a bug in 
your popFront function, etc.).

I've been meaning to write a blog post on this, but haven't had any time 
for it.

-Steve