On Saturday, 9 March 2013 at 16:22:43 UTC, monarch_dodra wrote:
> ...which brings us to managing said overloads. Basically, right now, if you want overloads, you have to repeat the conditions in a:
>
> if (a && !b)
> ...
> if (b && !c)
> ...
> if (c)
>
> This is minor, but it does not scale very well, especially if "a", "b" and "c" are complicated. In algorithm, some of our constraints for sort/find can be 5 lines long. At this point, can we still say that they are readable tools for users, or an implementation tool for dispatch?

I agree this is a problem. sort didn't have constraints for a long time. I added them not long ago, but if I'm being perfectly honest, I'm not 100% convinced I've done it correctly. It's incredibly difficult to examine a non-trivial function to see what the correct constraints are.

btw, you have a bug :-)  If the arguments match constraints a and c, but not b then the call will be ambiguous on the first and third.

Another problem with constraints is that if you want to add a specialisation, you can't do it without changing the existing functions, e.g.

void foo(R)(R r) if (isInputRange!R)

If I want to add a better version for random access ranges, I cannot just add:

void foo(R)(R r) if (isRandomAccessRange!R)

I also have to modify the original:

void foo(R)(R r) if (isInputRange!R && !isRandomAccessRange!R)

I suppose a better solution to this problem would involve someway of specifying that random access ranges are a subtype of input ranges, and the overload resolution would recognise that the random access range version is preferable to the more general version when available. I can't see a way to do this in general with constraints.

On 3/9/13 1:10 PM, Klaim - Joël Lamotte wrote:
> Note that there will be a teleconference Tuesday with one important point:
> "Discuss whether to continue work on static if, or to focus work on
> concepts lite."
> See:
> https://groups.google.com/a/isocpp.org/forum/#!topic/concepts/AMVFwQGgS3c
>
> I'm pointing that in case Alexandrescu and Walter didn't know and want
> to defend their paper.
>
> Joel Lamotte

Thanks, Joel.

Andrei

On 03/09/2013 10:10 AM, deadalnix wrote:

>> static_if >>
>> void foo();
>> <<
>>
>> Problem solved. ;)
>>
>> Ali
>
> static if(condition) «
> void foo();
> »
>
> Let's do it with style ;)

Ha ha! :) I remembered about those characters as well but only after posting mine.

Ali

On Sat, 09 Mar 2013 12:28:37 -0600
1100110 <0b1100110@gmail.com> wrote:

> On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
> > On Sat, 9 Mar 2013 02:08:07 -0500
> > Nick Sabalausky<SeeWebsiteToContactMe@semitwist.com>  wrote:
> >
> >> On Sat, 09 Mar 2013 01:48:55 +0100 "DypthroposTheImposter"<mcbracket@gmail.com>  wrote:
> >>
> >>>          See the static_if paper here:
> >>>
> >>> http://isocpp.org/forums
> >>>
> >>> Under the post "constraints and static if" there is a link to a
> >>> document about
> >>> static_if
> >>>
> >>> https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
> >>>
> >>>         Are they full of it? Has it caused the problems they
> >>> mention in
> >>> D?
> >>
> >> Does that document exist somewhere in a the form of a real web page? Or at least *any* real document format?
> >
> > To be clear, that's not a veiled attack on anything. I really *am* just simply asking if there's a link for that anywhere to a real file (html, pdf, text, wordperfect, gif, hell whatever.)
> >
> I converted it to pdf.  Do you want it?

Sure, please. If you could either post it here, or on the web, or email
nick1 at semitwist dot com, or whatever works for you that'd be
great. :)

On 3/9/2013 8:22 AM, monarch_dodra wrote:
> Things can get evenmore hairy,when you are operating on 2 different types.

This is why complex expressions can be encapsulated as functions.

>
> One last thing to keep in mind is that having constraints allows hijacking,
> whereas concpets/static asserts resolve as an ambigus call.

I don't see where the hijacking comes in.

On 03/09/2013 08:09 PM, Nick Sabalausky wrote:
> On Sat, 09 Mar 2013 12:28:37 -0600
> 1100110<0b1100110@gmail.com>  wrote:
>
>> On 03/09/2013 01:33 AM, Nick Sabalausky wrote:
>>> On Sat, 9 Mar 2013 02:08:07 -0500
>>> Nick Sabalausky<SeeWebsiteToContactMe@semitwist.com>   wrote:
>>>
>>>> On Sat, 09 Mar 2013 01:48:55 +0100
>>>> "DypthroposTheImposter"<mcbracket@gmail.com>   wrote:
>>>>
>>>>>           See the static_if paper here:
>>>>>
>>>>> http://isocpp.org/forums
>>>>>
>>>>> Under the post "constraints and static if" there is a link to a
>>>>> document about
>>>>> static_if
>>>>>
>>>>> https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
>>>>>
>>>>>          Are they full of it? Has it caused the problems they
>>>>> mention in
>>>>> D?
>>>>
>>>> Does that document exist somewhere in a the form of a real web
>>>> page? Or at least *any* real document format?
>>>
>>> To be clear, that's not a veiled attack on anything. I really *am*
>>> just simply asking if there's a link for that anywhere to a real
>>> file (html, pdf, text, wordperfect, gif, hell whatever.)
>>>
>> I converted it to pdf.  Do you want it?
>
> Sure, please. If you could either post it here, or on the web, or email
> nick1 at semitwist dot com, or whatever works for you that'd be
> great. :)
>

http://1100110.in/static-if.pdf

(Powered by vibe.d  =P)

On Sun, 10 Mar 2013 00:20:34 -0600
1100110 <0b1100110@gmail.com> wrote:
> 
> http://1100110.in/static-if.pdf
> 
> (Powered by vibe.d  =P)

Cool, thanks :)

On Sunday, 10 March 2013 at 02:35:28 UTC, Walter Bright wrote:
> On 3/9/2013 8:22 AM, monarch_dodra wrote:
>> Things can get evenmore hairy,when you are operating on 2 different types.
>
> This is why complex expressions can be encapsulated as functions.
>
>>
>> One last thing to keep in mind is that having constraints allows hijacking, whereas concpets/static asserts resolve as an ambigus call.
>
> I don't see where the hijacking comes in.

 From the bad examples I think he was meaning declaring new functions in the static_if that might not be in the other tree; But proper use of static if doesn't cause those problems.

On Sunday, 10 March 2013 at 02:35:28 UTC, Walter Bright wrote:
> On 3/9/2013 8:22 AM, monarch_dodra wrote:
>> Things can get evenmore hairy,when you are operating on 2 different types.
>
> This is why complex expressions can be encapsulated as functions.

Yes, but that doesn't solve the "root" issue of meaningfulness. Sure, instead of having a 5 line constraint, it's only a single line, but are these any better?

sort(R, Scheme)(...)
    if(isRandomAccessRangeWithComparableElementsAndAssignableElementsIfStableSchemeOrSwapableElementsOtherwise!R)

or

sort(...)
    if(meetsSortConstraints!R)

Neither are really any better for the end user.

This is why I don't think constraints should be used at all for validating arguments. [concepts|static asserts] are much better, and when combined with static if, become incredibly powerful:

sort(R, Scheme)(...)
{
    static assert (isRandomAccessRange!T);
    static assert (is(typeof(r.front < r.front)));
    static if (Scheme == Stable)
        static assert (hasAssignableElements!T);
    else
        static assert (hasSwapableElements!T);

    //Code Code Code
}

Much clearer, and the diagnostics much better.

That said, we can also look for a "middle ground" where the constraints validate the broad requirements (RA, comparable), and the asserts validate the more complex stuff.

>> One last thing to keep in mind is that having constraints allows hijacking,
>> whereas concpets/static asserts resolve as an ambigus call.
>
> I don't see where the hijacking comes in.

The problem with contraints is that it merelly eliminates functions from the pool of overloads. If you attemp to call a function with invalid parameters, then you may end up accidentally calling something you didn't want to. Imagine:

//----
module a;
void do_it(R)(R r)
    if (isForwardRange!R)
{
    //Do something to r
}
//----
module b;
void do_it(T)(T t)
{
    //Do something completely different
}
//----
import a, b;

void main()
{
    MyInputRange myInputRange; //Oops! I didn't realize it's only input:
    do_it(myInputRange); //meant to call a.do_it;
}
//----

With the current scheme of constraints, this will end up calling b.do_it, without any ambiguity. You may or may not consider that is "hijacking", but it is error prone.

NOW, if we had defined a.do_it with concepts/static asserts, the programmer would have been served with a "ambiguous call: a.do_it or b.do_it"? So the coder would have to be "alright, I want to explicitly call a.do_it". To which this time the compiler replies "Error: isForwardRange!MyInputRange is false". To which the programmer replies "I understand my error and see what I did wrong".

--------------------------------------

I'm not saying template constraints are bad or anything, I think they are incredible tools for dispatching to specialized overloads.

However, In regards to *validating* the input, I think concepts/static asserts, are both more robust implementation-wise, while being clearer for the end coder.

On Sunday, 10 March 2013 at 16:05:37 UTC, monarch_dodra wrote:
> I'm not saying template constraints are bad or anything, I think they are incredible tools for dispatching to specialized overloads.
>
> However, In regards to *validating* the input, I think concepts/static asserts, are both more robust implementation-wise, while being clearer for the end coder.

+1