On Saturday, 25 July 2015 at 10:01:43 UTC, Walter Bright wrote:
On 7/24/2015 10:59 PM, Jonathan M Davis wrote:
In any case, looking at this, I have to agree with you that
this is the same
problem you get with checked exceptions / exceptions
specifications - only worse
really, because you can't do "throws Exception" and be done
with it like you can
in Java (as hideous as that is). Rather, you're forced to do
the equivalent of
listing all of the exception types being thrown and maintain
that list as the
code changes - i.e. you have to make the top-level template
constraint list all
of the sub-constraints and keep that list up-to-date as the
sub-constraints
change, which is a mess, especially with deep call stacks of
templated functions.
Phew, finally, someone understands what I'm talking about! I'm
really bad at explaining things to people that they aren't
already familiar with.
I'm not sure, but I suspect this problem may cripple writing
generic library functions that do one operation and then
forward to the next (unknown in advance) operation in a chain.
Well, the caller then has to do deal with the fact that the
result doesn't work with the next call in the chain, and at least
in that case, the failures are at their level, not buried inside
of calls that they're making. And this is exactly the sort of
problem that we've had for quite a while where you try and do
something like
auto result = rndGen().map!(a % 10).take(10).sort();
The result of take isn't random-access, but sort requires
random-access, so you get a compilation failure - but it's
clearly on this line and not inside of one of the calls that
you're making, so it's pretty straightforward.
I guess that where the problem might come in (and maybe this is
what you meant) is when you try and do a chain like that inside
of a templated function, and you end up with a compilation
failure, because the argument to that function resulted in one of
the items in the chain failing. But I'm not sure that that's any
different really from a line with a single function call failing
due to the outer function's argument not working with it.
It also may completely torpedo Andrei's Design By Introspection
technique.
I'm not sure what you mean here. Design by Introspection seems to
be primarily for implementing optional functionality, and it
couldn't be in the outer template constraint regardless, because
it's optional. So, I don't really see how whether or not we put
all of the sub-constraints in the main template constraint really
affects DbI.
I do have to wonder about what Andrei means to do with DbI
though, since he keeps bringing it up like it solves everything
and should be used everywhere, whereas it seems like it would
only to apply to certain areas where you're dealing with optional
functionality, and a lot of code wouldn't benefit from it all.
We're essentially using it with ranges already when we're
implementing algorithms differently based on what type of range
we're given or what extra capabilities the range has, so it
obviously is showing its usefulness there, but the allocators is
the only other case that I can think of at the moment where it
would make sense to use it heavily. He sounds like he wants to
use it everywhere, which I don't get at all.
- Jonathan M Davis
