On 04/03/14 04:40, Walter Bright wrote: > On 4/2/2014 6:21 PM, bearophile wrote: >> Then this feature needs a specific and explicit syntax, or it has _no_ point >> at >> all. > > That's like saying inlining has no point because it doesn't have a particular > syntax.
Weak inlining *hints* have no point - C learned this the hard way, with "inline" being useless today, and everybody having to use "always_inline/forceinline". The issue isn't about optimizations, which any decent compiler can deal with; it's about the programmer being able to rely on avoiding certain undesirable effects, like excessive stack consumption, unnecessary clobbering of the few precious cpu registers available etc. What Bearophile is saying is that an optional tail call optimization being mandated by a spec would be completely useless -- TCO can be legally done by the compiler anyway; documenting that it could happen does not help the programmer in any way - (s)he still has to assume that the optimization might not happen. A syntax like "goto return f();" which mandates TCO would make the situation different. [Defining computed gotos would be a better idea, as the tail-call transformation would significantly raise the requirements for a compliant D compiler. OTOH computed-gotos would lead to more readable D code, are easier to implement, and can be easily be made safe in D (by making the type of label-addresses unique per-function and avoiding function-cloning)] artur