On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
> On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
>> "Walter Bright"  wrote:
>>
>>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
>>
>> Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
>
> Is there more constructs than static if that doesn't create a scope?

version, debug, release, const/immutable/inout/static/whatever{} .

On Saturday, 9 March 2013 at 09:52:55 UTC, deadalnix wrote:
> On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
>> On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
>>> "Walter Bright"  wrote:
>>>
>>>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
>>>
>>> Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
>>
>> Is there more constructs than static if that doesn't create a scope?
>
> version, debug, release, const/immutable/inout/static/whatever{} .

I see const++ as well as property as qualifiers and don't assume a new scope.
Didn't think of version++ though :)

On 03/09/13 05:34, H. S. Teoh wrote:
> On Fri, Mar 08, 2013 at 07:50:26PM -0800, Walter Bright wrote:
>> On 3/8/2013 5:19 PM, Brad Anderson wrote:
>>> On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
>>>>      Are they full of it? Has it caused the problems they mention
>>>> in
>>>> D?
>>>
>>> Well, the two guys with an alternative proposal (concepts-lite) seem
>>> to hate static if (along with a third guy).
>>>
>>> There seems to be a lot of strawman arguments in this paper.
>>
>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
> 
> I didn't read the paper, but I have to say that static if in D has been extremely, extremely useful in my code. Now that I've become acquianted with it, I can't live without it. It's pretty much a necessity when writing heavily-templated code. But given C++'s broken template design, I can see why its value may not have been appreciated by some people.
> 
> D may still have its warts, but in terms of being a "better C++", I think it has done a superb job, especially in the area of templates and compile-time mechanisms. Static if + CTFE + sane template syntax = readable template code = total win for D over C++.


Let me quote a paragraph from that paper:
> Being a new and realtively simple-to-use new feature, static_if would un- doubtedly be used by many who have no need for the relatively small increme- natal improvement in performance offered. The library writers for which such techniques really are important, already have to tools and skills needed.

No skilled Real Programmer would ever use a language feature that was simple to use.

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?
 - (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,
    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.

artur

On Saturday, 9 March 2013 at 09:41:42 UTC, simendsjo wrote:
> On Saturday, 9 March 2013 at 09:12:30 UTC, Jouko Koski wrote:
>> "Walter Bright"  wrote:
>>
>>> Many of the criticisms in the paper are addressed by our positive experience with static if in D.
>>
>> Sometimes I do find it confusing that { does or does not introduce a new scope in a very similar-looking contexts.
>
> Is there more constructs than static if that doesn't create a scope?

"Labeled scopes" (ironically) don't create scopes. Eg:

//----
some_label:
{
    int a;
    //Code code code
}
a = 5;
goto some_label;
//----

That doesn't actually create a new scope, and that assignement is legal game.

This is from the official documentation, so it is not a bug. I can't, for the  life of me, understand why it is that way, in particular, since it deviates from C. I see it as a "never better, sometimes worst" approach.

I've tried to ask about it before, but I best, the answer I got was "works as documented", but still have no idea on the why :/ ???

And since goto is "evil", I think very few people care, so getting any kind of activity about this is hard.

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

Greetings

I believe the paper takes a contrived route to criticize "static if". It takes some bad code examples which are not obvious use cases of "static if" and then goes on to say that the resultant code is not good. I think the code example to begin with was not good.

Regards
- Puneet

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

I think there is a bit of forced bashing in there, but the main point is that static if prevents eager semantic validation of templated code. In C++, if you write a semantically incorrect template, then the compiler can catch it. This is not possible once static ifs enter the picture.

I know for a fact I've had the C++ compiler catch a fair amount of errors for me, whereas it takes actual intantiation for the D compiler to catch said errors (and I've seen a few such errors in phobos).

I think the main point is not "is static if good or not": I think D has clearly demonstrated how powerful it can be. However, to the question of "is it the right move for C++, whith all of its heritage, to adopt static if?" As a C++ developper, honestly, I'm not sure it is. I think that's where the piece is comming from, in maybe a clumsy manner.

C++ took a different road with its "horrible" template syntax, but it took that road. I think it is better to improve that road (with concepts, for example), then try to move the current paradigm.

That's might point of view having mostly a "full C++" background, and having learned D. The bottom line, I think, is that it is an error to think of D as "just" improved C++, and that what might work for D might not be what is best for C++. It doesn't mean that static if (or other D constructs) are bad in and out of themselves. I wouldn't take this piece as a "direct attack" on D.

...

BTW, in regards to template constraints (not the rest), he does have a point. We have raised the exact same issues here on the boards more than once.

On Saturday, 9 March 2013 at 14:49:36 UTC, d coder wrote:
> Greetings
>
> I believe the paper takes a contrived route to criticize "static if". It takes some bad code examples which are not obvious use cases of "static if" and then goes on to say that the resultant code is not good. I think the code example to begin with was not good.

Agreed. Just barely started reading it and it appears they're nit-picking about something they would have trouble with if it was scoped or not, but more importantly they aren't considering something we would do automatically. If you declare in one, you declare in the other, only difference may be a few details like storage types, removing some of the problems entirely; So he's attacking something that could be done in the preprocessor anyways; Or maybe he's attacking bad coding style but isn't expressly saying it?

[quote]
Conditional compilation, the selective inclusion of statements in a translation unit, is a conventional example. Consider a simple example of introducing some declarations, depending on whether the size of some type, T.

  static if (sizeof(T)==8) {
    void fun();
    void gun(int);
  } else {
    void gun();
    typedef tx int;
  }

The semantics of the program are this: if sizeof(T)==8, the compiler will parse the statements in the “then” branch, and will tokenize and brace-match the declarations in the else branch. Those other declarations would be uninterpreted by the compiler.

Note that unlike normal if statements, the braces enclosing the conditionally compiled statements do not introduce a new scope. Those declarations are declared into the scope enclosing the static if block. This difference makes
code written using static if harder to read and understand—modulating between static and non-static ifs in a single block provides ample opportunities for confution and mistakes.

The effect of this declaration is to conditionally modify the current scope with a set of new declarations. How can we know, later in the program, which version of gun we should use, or whether tx is defined or not? Any use of those
declarations would also need to be wrapped.

  static if (sizeof(T)==8)
    gun(32);
  else
    gun();
  static if (sizeof(T)==8) {
    long n = x;
  }
  static if (sizeof(T)!=8) {
    tx n = x;
  }

Thus, the use of static_if for conditional compilation is viral.
The impact of conditional parsing on program analysis tools is substantial. While the feature may be easily implemented as part of the translation process, program analysis tools have traditionally struggled with conditional declarations. The inclusion of multiple variants (via, e.g., preprocessor conditions) and simultaneous repersentation within a single program model is still an open problem in the source code analysis communities. Adopting static if will make analysis harder, not easier.
[/quote]

 And I'm sure that using the preprocessor keeps things simple right? Geez let's take a C/C++ version of that... Preprocessor tokens may be off, but the point should get across... :P

  #ifdef X
    void fun();
    void gun(int);
  #else
    void gun();
    typedef tx int;
  #endif

 And

  #ifdef X
    gun(32);
  #else
    gun();
  #endif
  #ifdef X
    long n = x;
  #endif
  #ifndef X
    tx n = x;
  #endif

[quote]
We have already heard suggestions of static_for and static_while. Can static_switch be far behind? C++ would become a low-level, unprincipled hackers’ favorite playground. In our opinion, if you want compile-time computation, look to constexpr, which does have a sane and typesafe underlying model.

If we do not provide a static_for, hackers will simply make one out of static_if or fake equivalents.
[/quote]

 C++ is just as low level as C, this statement is useless. Being against 'static_for' is kinda dumb since if you think about it, it just unrolls the loop ahead of time instead of optimization, other than that it shouldn't do anything odd. I'll agree not to add static_for only because it's not really needed.

[quote]
The semantics of static_if are to tokenize the branch not taken. If the condition is dependent, as it is in the statements above, then the compiler must not parse either branch. Both branches are tokenized since either one could
contain compiler-specific extensions—or both, or neither. That won’t be known until both branches would have been fully parsed.

<snip>

Consider the real world impact of this design choice. The inability of the compiler to parse the branches of the compiler means that the library writer will need to instantiate every branch of the template just to ensure that the syntax is correct and that no spelling errors have been made. Today, this is done, to a large extent, by the compiler
[/quote]

 In C++ you need to have EVERYTHING loaded (declarations, etc) loaded before you can compile anything, Unlike in D where all tokens effectively have one meaning as intended, so the whole template issues aren't an issue. Seems like they're just opening their own cans of worms :P

[quote]
The trailing if clause enforces a requirement that T must be convertible to the value_type of I. We most strongly agree that some mechanism is needed for constraining templates, this is particular syntax leaves much to be desired.
It is particularly verbose, and leaves the entire body of the template unchecked. The body must only be tokenized because the static condition could guard the instantiation against compiler-specific extensions in the nested code. That fact would only be ascertainable after the entire body is parsed.
[/quote]

 Deja-vu, until recently (C++11) when they changed 'auto' to accept any type didn't they have to be super verbose everywhere anyways? Verboseness shouldn't matter in templates so much as it's user code that needs to be clean. Microsoft core teams admit their STL they write and maintain is ugliest and basically illegible to anyone outside the team; Although template structure as C++ is and their STL doesn't help much.

[quote]
The static if feature might also be used to support overloading. Below is an implementation of advance.

<snip>

Because static if only allows for Boolean decisions, overloading on a set of overlapping constraints requires the programmer to write bounding predicates like those above (e.g., input iterator but not bidirectional, bidirectional but not random access, etc...). This model of overloading is brittle, error-prone, verbose, and defines a “closed world”. No other overloads may be considered without modifying the constraints on the existing declarations in order to ensure consistency.
Declarations might be condensed using else clauses, but this is only cosmetic.
[/quote]

 *gasp* Walter! Did you know static if only allows boolean decisions! My god our static if MUST is be error-prone and brittle, a 'closed world'!

 *Note sarcasm*

 I'll agree a modification for handling nested static if's or something could be nice, but it's not unmanageable if you keep it relatively small. Hell what am I talking about? People go above and beyond a language to do stuff I wouldn't even consider, like a full x86 emulator in JavaScript..

[quote]
The use of static if might also be used to reorder data structures for tighter alignment, but this is a potentially dangerous idea that could lead to bugs that are exceptionally difficult to diagnose and fix.
[/quote]

 Doesn't he mean the pre-processor?

  #define max(x,y) x > y ? x : y

  int a = 1, b = 2;
  z = max(a++, b++);

  struct X {
  #ifdef TIGHT
    int x;
    char y[100];
  #else
    char y[100];
    int x;
  #endif
  }

 The largest complaint he has is managing tokens and being able to figure out what is what; In short previous bad decisions on the language HE HIMSELF MADE are preventing potential growth of the language making static if in his mind, unmanageable, yet you can do anything with the preprocessor (well, no CTFE...).

On 3/9/13 10:22 AM, monarch_dodra wrote:
> BTW, in regards to template constraints (not the rest), he does have a
> point. We have raised the exact same issues here on the boards more than
> once.

What was the problem for D again?

Andrei

On Saturday, 9 March 2013 at 14:09:39 UTC, Andrei Alexandrescu wrote:
> Wow. That's quite out of character for Bjarne. I think it's quite a poor piece.

I agree.  I stopped reading at "The purpose of this paper is to examine the negative impact of the static if proposal [...]".

Not "the impact", but "the *negative* impact".  That doesn't exactly set the stage for a very nuanced discussion.

Lars