On Wednesday, 25 July 2012 at 07:23:51 UTC, Jacob Carlborg wrote:
On 2012-07-25 07:30, xenon325 wrote:
For this to be useful you really need to create a template
for every condition
[snip]
With my approach the constraint will have a name which should
result in a lot better error messages.
H
On 2012-07-25 07:30, xenon325 wrote:
How is it different from creating a template for every condition ? ;)
As long as you actually _do_ that, it might not be so much different.
Honestly, I don't quite get what's the difference between current
template constraints and ones you're proposing:
On Tuesday, 24 July 2012 at 12:50:08 UTC, Jacob Carlborg wrote:
That will be just a little better. The problem is it will leak
implementation details. For this to be useful you really need
to create a template for every condition:
template isFoo (T)
{
enum isFoo = is(T == Foo);
}
void fo
On 2012-07-24 10:37, xenon325 wrote:
I remember this was discussed recently and Don Clugston suggested
something like this:
if there is no match for:
void foo(T)(T t) if( !conditionA!T ){}
void foo(T)(T t) if( conditionA!T && conditionB!T ){}
the error will be:
template foo does no
On Monday, 23 July 2012 at 19:57:42 UTC, Jacob Carlborg wrote:
constraint BidirectionalRange (Range) : ForwardRange!(Range)
{
void popBack ();
@property E back ();
@property E front ();
}
[snip]
I know that others have had similar ideas.
I remember this was discussed recently and
On 2012-07-23 22:28, monarch_dodra wrote:
My fear is that no matter how you look at it, the compiler just doesn't
know which overload you want to call. If the compiler could generate
messages about why each overload was not satisfactory, and it would have
then to generate messages about each and
On Monday, 23 July 2012 at 19:57:42 UTC, Jacob Carlborg wrote:
[snip]
I know that others have had similar ideas. In these cases I
think the compiler should be able to give clear and proper
error messages when something fails to match because now the
range constraints/interfaces have names. Som
On 2012-07-23 16:47, Andrei Alexandrescu wrote:
The assertive input validation has the problem it prevents an overload
outside of std.algorithm from working.
I think we should focus here on the compiler giving better information
about which part of the Boolean constraint failed.
I would like
On 7/23/12 7:10 AM, monarch_dodra wrote:
[snip]
How do you feel about "assertive input validation" vs "conditional
implementation"?
Is this something you'd like to see more of in algorithm?
The assertive input validation has the problem it prevents an overload
outside of std.algorith
On 23-Jul-12 18:07, Simen Kjaeraas wrote:
On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud
wrote:
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky
wrote:
Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and
they
are suppos
On Mon, 23 Jul 2012 15:49:43 +0200, Philippe Sigaud
wrote:
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky
wrote:
Will explode every time a constraint is tested?
After all constraints do fail so that other function is picked up and
they
are supposed to.
Damn, you're right.
To be
On Mon, Jul 23, 2012 at 3:39 PM, Dmitry Olshansky wrote:
> Will explode every time a constraint is tested?
> After all constraints do fail so that other function is picked up and they
> are supposed to.
Damn, you're right.
On 23-Jul-12 17:29, Philippe Sigaud wrote:
On Mon, Jul 23, 2012 at 1:44 PM, Chris NS wrote:
And for the curious, what I mean by embedding assertions in the conditions
is quite literally what it sounds like:
Range minPos ( Range ) ( Range R1 )
if( is( inputRange!Range ) )
assert( !isInfinite!R
On Mon, Jul 23, 2012 at 1:44 PM, Chris NS wrote:
> And for the curious, what I mean by embedding assertions in the conditions
> is quite literally what it sounds like:
>
> Range minPos ( Range ) ( Range R1 )
> if( is( inputRange!Range ) )
> assert( !isInfinite!Range, "minPos cannot operate on inf
It certainly makes sense. Maybe the long term solution would be
a way to embed those assertions in the conditions, but in the
meantime the proposal would alleviate the error message issue. I
know I've often enough stared long and hard at a volume of
template instantiation errors waiting for t
On 2012-07-23 13:10, monarch_dodra wrote:
I've been putting my nose in std.algorithm recently, specifically,
requirements of algorithms.
I must say I'm a big fan of conditional implementations. Given the
genericity of templates (!), it can be very hard to overload them
correct without conditiona
On Monday, 23 July 2012 at 11:10:39 UTC, monarch_dodra wrote:
Is this something you'd like to see more of in algorithm?
Yes! Improving error messages is very important. Maybe we find a
better solution on compiler level but in the meantime [not only]
std.algorithm will benefit from your solut
I've been putting my nose in std.algorithm recently,
specifically, requirements of algorithms.
I must say I'm a big fan of conditional implementations. Given
the genericity of templates (!), it can be very hard to overload
them correct without conditional implementation. It is a really
useful
18 matches
Mail list logo
