On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter 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?

It is hard for me to say, they continued to bring up that they have better tools to achieve some of the items (constexsp) but don't give an example of what that code would look like.

It seems like they aren't actually looking for serious discussion on the matter; "C++ would become a low-level, unprincipled, hackers’ favorite playground." as apposed to what it is now a low-level, unprincipled, playground no hacker would play in unless they had to? That combined with not wanting to include a "realtively simple-to-use new feature" really makes it hard to take the paper seriously.

As for template constraints, we do have issues in D; monarch_dodra has been good to go over those. I'm glad we have them, but they are not without their faults.

On 3/10/2013 9:05 AM, monarch_dodra wrote:
> 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.

I don't think this issue is any different from selecting a name for any function that does something non-trivial. It's why we have functions - to encapsulate complexity.


> 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.

Whether it's clearer or not is all in how you choose to organize/write them. Also, the static assert model does not enter into overload selection, while constraints do.



>>> 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.

That is not hijacking. Hijacking is when a template or function **from an unrelated scope** matches better and steals the call away. When templates/functions are in the same scope, it is just a usual overloading issue. It's not an undue burden on the programmer to pay attention to the overloads in the same scope. He's got to do that anyway.

On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu wrote:
> On 3/8/13 7:48 PM, DypthroposTheImposter 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?
>
> Wow. That's quite out of character for Bjarne. I think it's quite a poor piece.
>
> Andrei

Indeed, from the start, it doesn't seem to give a fair assessment of the value of the feature.
As for rejecting your proposal, don't take it too personnally. In the contrary, the inclusion of static if would have been the single reason for C++ users not to migrate en masse to D. Think that there won't be a good solution for C++ before another 20 years. By the time it is proposed, this is a good opportunity for D to mature and conquer hearts.

On Sunday, 10 March 2013 at 22:49:53 UTC, SomeDude wrote:
> On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu wrote:
>> On 3/8/13 7:48 PM, DypthroposTheImposter 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?
>>
>> Wow. That's quite out of character for Bjarne. I think it's quite a poor piece.
>>
>> Andrei
>
> Indeed, from the start, it doesn't seem to give a fair assessment of the value of the feature.
> As for rejecting your proposal, don't take it too personnally. In the contrary, the inclusion of static if would have been the single reason for C++ users not to migrate en masse to D. Think that there won't be a good solution for C++ before another 20 years. By the time it is proposed, this is a good opportunity for D to mature and conquer hearts.

Concepts have some drawbacks, but are also supperior in many way to static if. This isn't a black and white situation.

On Saturday, March 09, 2013 01:48:55 DypthroposTheImposter 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=MDIyMDc3NjUwMTczOTM0Mjk3 NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
> 
>        Are they full of it? Has it caused the problems they mention
> in
> D?

I haven't read the paper, so I really don't know what problems they see with static if, and C++ _is_ a very different beast than D (particularly with regards to stuff done at compile time), but without statif if, C++ seems very crippled with regards to templates and conditional compilaton. The combination of template constraints and static ifs is _extremely_ powerful in D, and it works very well. C++ currently lacks anything of the sort, and until it does, it's templates will be very much inferior to D's. Maybe they can gain similar power through different mechanisms, but I'm surprised that anyone would think that static if was such a bad idea. It's working fantastically well for us, and I don't know how we'd get along without it.

- Jonathan M Davis

On Monday, 11 March 2013 at 02:39:47 UTC, Jonathan M Davis wrote:
> I haven't read the paper, so I really don't know what problems they see with static if, and C++ _is_ a very different beast than D (particularly with regards to stuff done at compile time), but without statif if, C++ seems very crippled with regards to templates and conditional compilaton. The combination of template constraints and static ifs is _extremely_ powerful in D, and it works very well. C++ currently lacks anything of the sort, and until it does, it's templates will be very much inferior to D's. Maybe they can gain similar power through different mechanisms, but I'm surprised that anyone would think that static if was such a bad idea. It's working fantastically well for us, and I don't know how we'd get along without it.

 It basically comes down to syntactical analysis, being able to tell if code is written right (when blocks end as well), which goes with their templates and use of <>'s; Which I'm glad to see D isn't crippled in that way.

 The another part is how static if becomes 'viral' as you'd have to use 'static if' in every spot elsewhere in order to keep it in line; However the example shown is bad programming practice and; You can duplicate very easily using the preprocessor.

 A third part of it was how 'verbose' they would have to be to check constraints, but with how just before C++11 they were verbose everywhere, so why it is verbose in constraints as his problem I am not sure.

On 09/03/2013 11:15, Artur Skawina wrote:
> Seriously though, they point out several problems, some of which are C++
> context specific (like mixing CPP w/ static-if and lack of introspection).
> Other mentioned issues are not real problems in practice, or not even
> problems at all.
>
> What's left is:
>   - static-if not creating scopes/is/  confusing, but what would be a better
>     alternative?

Isn't it only confusing to newbies? It's not hard to learn and recognize.

>   - (static-)if in templates or as template constraints -
>      a) prevents pre-instantiation verification - true, applies to D, but
>           not really a big problem, assuming sane application of static-if,

Maybe a concept-based static if would work for C++? That would allow pre-instantiation verification, but still allow flexible code. The concept test would only allow concept features within the static if branch.

>      b) make constraint-based overloading ugly and fragile - true, something
>           better is needed for D too. But until that exists, careful use
>           of constraints mostly works.

"Nick Treleaven" wrote:
> On 09/03/2013 11:15, Artur Skawina wrote:

> >   - static-if not creating scopes/is/  confusing, but what would be a better
> >     alternative?
>
> Isn't it only confusing to newbies? It's not hard to learn and recognize.

Maybe. This is just precisely the way how it all begun in C/C++.

-- 
Jouko 

On 03/11/2013 07:55 PM, Jouko Koski wrote:
> "Nick Treleaven" wrote:
>> On 09/03/2013 11:15, Artur Skawina wrote:
>
>> >   - static-if not creating scopes/is/  confusing, but what would be
>> a > better
>> >     alternative?
>>
>> Isn't it only confusing to newbies? It's not hard to learn and recognize.
>
> Maybe. This is just precisely the way how it all begun in C/C++.
>

Actually, in D, static if creates its own scopes for declarations made inside the static if condition.

On Monday, March 11, 2013 20:14:07 Timon Gehr wrote:
> Actually, in D, static if creates its own scopes for declarations made inside the static if condition.

No, it doesn't, and it would be _way_ less useful if it did, particularly with regards to struct and class definitions. Take this code, for instance,

import std.stdio;

static if(true)
    int var = 7;
else
    string var = 12;

void main()
{
    int i = var;

    static if(is(typeof(var) == int))
        int j = 22;
    else
        float j;

    writeln(j);
}

It compiles just fine and prints 22. Both the static if at module-level and the one in the function declare variables which are used outside of the static if blocks. static if does _not_ create a new scope. And putting braces around the static if bodies has no effect on the scoping either.

- Jonathan M Davis