C++ guys hate static_if?

H. S. Teoh hsteoh at quickfur.ath.cx
Thu Mar 14 15:57:59 PDT 2013


On Thu, Mar 14, 2013 at 06:18:58PM -0400, Andrei Alexandrescu wrote:
> On 3/14/13 6:02 PM, H. S. Teoh wrote:
> >On Thu, Mar 14, 2013 at 05:54:05PM -0400, Andrei Alexandrescu wrote:
> >>On 3/14/13 2:38 PM, Jonathan M Davis wrote:
[...]
> >>>Though this is exactly a case where 100% unit test coverage doesn't
> >>>mean much.  All that means is that each path has been instantiated
> >>>and run. It doesn't mean that it's covered enough possible
> >>>instantiations to properly test the template.
> >>
> >>Concepts won't help there either.
> >[...]
> >
> >It does help. For example, if the code wrongly assumes mutability for
> >a particular template type, then it may work for most test cases
> >(frankly, I find const/immutable unittest coverage in Phobos very
> >poor) but fail when some daring user passes const(T) instead of T to
> >the template. For example, you may have accidentally written the
> >equivalent of:
> >
> >	auto func(T)(T t) {
> >		Unqual!T u = t; //<-- spot the bug
> >		...
> >	}
> >
> >Under a concepts system, this would be caught early because the
> >compiler would detect a concept mismatch (Unqual!T != T) when
> >analysing the template code.
> >
> >Currently, though, if there is no unittest that tries instantiating
> >the template with const(T), the bug goes undetected, because in all
> >*tested* instantiations, Unqual!T == T.
> 
> Template constraints start from the most permissive end of the
> spectrum: by default there's no verification, and constraints add
> verification.
> 
> With typeclasses it's the other way around: by default nothing is
> allowed, so code needs to add permissions explicitly.

I like this way of looking at it. So basically, typeclasses force us to
state all assumptions up-front, whereas template constraints leave room
for oversight (forget to put isForwardRange!R in the constraints but use
.save in the function body).


> I agree that in that regard typeclasses are better than template
> constraints. Of course there are many other aspects to be considered
> when comparing the two.
[...]

Yes, and I'm not saying that we should discard template constraints and
adopt typeclasses wholesale. I can't say I'm totally sold on typeclasses
either, because they do introduce their own tradeoffs. But neither
should we dismiss the typeclasses approach so lightly.

In fact, now that I think of it, templates in general suffer from this
problem: when you write template X(T) { ... }, pretty much anything goes
in the template body, even outright ridiculous things that won't compile
for *any* template arguments. But more commonly, the template body may
assume things about T that don't apply across all types T. You may
assume that T is mutable, or that T has a certain member, etc..

What if templates were modified so that assumptions about T have to be
stated up front? We don't necessarily have to introduce typeclasses as a
separate thing, but we could have the compiler reject template bodies
that try to access internals of T that aren't stated up front. E.g.:

	auto myFunc(T)(T t) {
		return t.fun();	// error: T wasn't stated to have a member named .fun
	}

would produce a compile error, whereas:

	auto myFunc(T)(T t)
		if (hasMember!(T, "fun"))
	{
		return t.fun();	// OK: we stated that we expect T to have a .fun member
	}

would be accepted. The stated assumptions can themselves be templates
too, which are expanded by the compiler before checking the template
body. (Presumably, hasMember will eventually expand to some compiler
intrinsic that tells the compiler what assumptions are being made about
T.) So we can still continue using things like isInputRange!T, etc.,
except that now the compiler will catch unstated assumptions.

IOW, make signature constraints mandatory rather than optional.
Arguably, signature constraints *should* be mandatory in
properly-written generic code anyway, so this can only add value. And it
will not break existing code if said code is properly-written.


T

-- 
The right half of the brain controls the left half of the body. This
means that only left-handed people are in their right mind. -- Manoj
Srivastava


More information about the Digitalmars-d mailing list