Thread: new standard

Originally Posted by grumpy

The paper listed the arguments for deprecation of exception specifications (and the underlying concern is that they are not checked statically). However, the focus of the paper was actually on fixing concerns associated with move constructors - essentially by specifying they will not throw - not on fixing wider concerns with exceptions.

The paper also noted that variants of throw specification are an alternative. On one hand, throw specifications are already discouraged and relatively rarely used (that's the core of the argument for their deprecation). Given that, the argument of "having too many syntactic similarities confuses the semantics of the two features in a way that is likely to cause problems for programmers" is a rather weak argument against overhaul of the semantics of exception specifications. Particularly when the "two features" are both related to exception handling.

It is one thing to discourage people from using throw declarations, it is another to replace it with something else. The latter will break some existing code; the former will not.

Perhaps, if they depreciate throw declarations now, then ten years time it will make sense to replace it with something else, but no sooner.

Originally Posted by phantomotap

My prediction is that programmers who understand the intent and capabilities of "rvalue references" will always use them. (Providing at least move assignment and move construction operators for anything not trivially copied.)

The whole problem is one of what is a "trivial" copy versus a move essentially being a destructive copy. To use the example of a swap() function

Code:

template<class T> swap(T &a, T &b)
{
      T tmp(move(a));
      a = move(b);
      b = move(tmp);
}

Where move() essentially enables the move construction or assignment. The thing is, in the first line it effectively destroys the object a. The second line then reconstructs a, with the contents of b, and destroys b. The last line then reconstructs b with the data that was in a.

Granted, there are efficiency gains ... if everything goes right. But one of the common maintenance problems in classes with user-supplied copy constructors or assignment operators has been the problem of ensuring those functions work correctly (eg correctly copy all members). And what does the "move construction" introduce ..... a requirement to potentially maintain a larger set of such functions. Unless performance is highly critical - which it is in some applications, but not in many - that is, on the face of it, a maintenance burden.

All this is at odds with accepted best practices, that encourage getting code functionally right first in the simplest and most maintainable form, and then worrying about addressing any performance deficiencies - in other words, discouraging premature optimisation. Instead, what we have is an encouragement for programmers to perform premature optimisation. That will eventually yield a series of constraints and guidelines concerning whether a class should support move construction/assignment or not. We already have an example where constraints have to be imposed related to exceptions. A few more such constraints - particularly if they rely on losts of care and consideration by the programmer - and it will be easier for programmers (who, let's face it, are often careless and inclined to waste productive time with premature optimisation) to use other techniques.

Yeah, I'm sure others will make different predictions to mine. The proof will be in the practice down-track, I guess. As a matter of fact, I hope I'll be proven wrong, but don't think I will be.

Originally Posted by King Mir

Perhaps, if they depreciate throw declarations now, then ten years time it will make sense to replace it with something else, but no sooner.

There are only two possible circumstances I can see in which changing exception specifications will cause confusion.

1) Addition of new constructs, which fail to compile at present anyway. This will only cause confusion if new code is ported to old compilers, but that's a common problem with all new language features. Deprecation will not stop programmers from running new code through old compilers.

2) Practical problems associated with turning run-time checks (eg calling abort() when an unexpected exception is thrown) into compile time checks.

Would you care to characterise practical circumstances in which changing current run-time enforcement of exception specifications to compile time checks presents a real disadvantage?

Yes, it is true that some old code will fail to compile. I consider those circumstances are a non-issue. Firstly, the amount of such code is small (since exception specifications have been actively discouraged - to the extent there is consideration of deprecating exception specifications). Second, the cause of failure will, most likely, be related to existing undiagnosed faults in code.

Originally Posted by grumpy

Firstly, the amount of such code is small (since exception specifications have been actively discouraged - to the extent there is consideration of deprecating exception specifications).

Sure, the amount of code is small, but the committee decided to be extra conservative here. Better to not break any previously valid code at all.

Second, the cause of failure will, most likely, be related to existing undiagnosed faults in code.

No I think the greatest the cause of the failure will be due to inconsistent use of throws decelerations.