std.format and uninitialized elements in CTFE
schveiguy at gmail.com
Mon Dec 9 16:26:10 UTC 2019
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"
Those libraries usually go something like this:
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
More information about the Digitalmars-d