allSatisfy could use some constraints
Jonathan M Davis
jmdavisProg at gmx.com
Thu Sep 22 16:52:05 PDT 2011
On Thursday, September 22, 2011 16:45 Jonathan M Davis wrote:
> On Thursday, September 22, 2011 15:36 Andrej Mitrovic wrote:
> > import std.string;
> > import std.traits;
> > import std.typetuple;
> >
> > void main()
> > {
> > if (allSatisfy!(isNumeric, int, short))
> > {
> > }
> > }
> >
> > D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\typetuple.d(576): Error:
> > template instance F is not a template declaration, it is a overloadset
> >
> > This took a good while to figure out what went wrong. std.traits
> > defines isNumeric, but std.string defines it too. allSatisfy takes an
> > alias type parameter with no constraints, so maybe some constraints
> > could be added so it doesn't get instantiated with regular functions
> > but only template functions?
>
> Well, the simple solution is to just pass it std.traits.isNumeric. As
> annoying as it may be at times, conflicting functions is something that
> can happen in D and has been planned for, so there are simple ways around
> the problem. However, if you're absolutely certain that it doesn't make
> sense for allSatisfy to work with a function as opposed to an eponymous
> template (and I'm not at all certain that that's true), then you can open
> an enhancement request.
Though given that allSatisfy!(isNumeric, int, short) will work with
std.traits.isNumeric and not std.string.isNumeric, I suspect that a template
constraint could be added which would fix the problem simply by checking
whether the compilation succeeds or not with the given arguments. And that
would be a better solution regardless of whether any normal functions
should work with allSatisfy or not.
- Jonathan M Davis
More information about the Digitalmars-d-learn
mailing list