On 25/03/2021 11.12, Jens Gustedt wrote:
>> Special-casing call_once in all of this seems to be very much a
>> quality-of-implementation concern. Every implementation should
>> choose whether it wants to teach its optimizer about the
>> special "call_once" properties. (After all, this is all about
>> optimizations, which are optional anyway.)
>
> I think that I don't agree completely. The text should make guarantees
> about the data dependencies that can be induced by calls to C library
> functions. `call_once` is one of them, and in addition it has very
> special semantics that are relevant for the properties at hand.
> So something should be said in one form or another.

Ok, but maybe that's a property of this particular function
(that should be stated near where it's specified) instead
of something we need to talk about in the specification of the
attributes.

This has practical impact for C++: We "inherit" (almost) all
of the C standard library, but none of the core language.
So, if the relevant text for call_once goes into the
call_once specification, chances are we'll get its properties
"for free" into C++. (Hm... I just realized C++ doesn't
provide <threads.h> at all, so maybe the "inheritance" argument
doesn't apply for this particular situation.)

Thanks,
Jens (the other one)


> Thanks
> Jens
>
> on Thu, 25 Mar 2021 10:44:09 +0100 you (Jens Maurer via Liaison
> <liaison_at_[hidden]>) wrote:
>
>> These look like possibly useful attributes for C++ as well,
>> but the wording needs to be totally redone.
>>
>> First of all, these attributes assert certain facts about a
>> function to the compiler, which possibly cannot be deduced by
>> the compiler.
>> This is most useful if the compiler cannot "see" the definition
>> of the function. However, this wording contains quite a bit
>> of text talking about "is implied", meaning that the
>> compiler analyzes a function definition and then implicitly
>> adds the attribute to the definition. But if the
>> compiler can "see" the function definition, there is little
>> need for an implied attribute in the first place, because the
>> compiler already has all the information it can possibly infer
>> about the function (and it might inline the call anyway).
>>
>> I'd like to see some explanation in the prose why the "is implied"
>> parts of the proposal are worth having. If "is implied" goes
>> away, the wording should be rephrased in the form of
>> assertions that the user makes, and should give the user
>> liberty to assert any function, without further constraints
>> on what the function actually does.
>>
>> Special-casing call_once in all of this seems to be very much a
>> quality-of-implementation concern. Every implementation should
>> choose whether it wants to teach its optimizer about the
>> special "call_once" properties. (After all, this is all about
>> optimizations, which are optional anyway.)
>>
>>
>> - It would help me if the wording would show monospace font where the
>> standard does, for example in 6.7.11.1 p2 (list of attribute names)
>> and 6.7.11.6 p1 (same).
>>
>> - "shall only appear" -> "shall appear only"
>>
>> - Since the new function attributes want to apply to a function
>> as declared (and not to the function type), they should apply to
>> the declarator-id and not to the entire function declarator.
>>
>> - 6.7.11.6 p2 the first two sentences can be merged
>> "... that belongs to a function declarator that declares a function."
>>
>> - "forms the definition" is novel phrasing, and I don't know what it
>> means.
>>
>> - p4+5 seems to contain tutorial material that shouldn't be in
>> normative text
>>
>> - 6.7.11.6.1 noleak: Any function -> All functions
>>
>> Why do we have to mention allocation functions explicitly? They
>> certainly don't carry the "noleak" attribute, so the first bullet
>> covers them nicely.
>>
>> - 6.7.11.6.1 noleak: p3 This appears to define the term "storage
>> leak", but it's not used going forward. "can be deduced by the
>> translator" seems vague at best: some compilers can deduce more than
>> others; the specification of the standard needs to draw the line by
>> explicitly saying what's going on.
>>
>> - p4 "with the exception of an allocated return value"
>> What does that mean, exactly? When is a return value "allocated"?
>> Also "shall be" sounds like a Constraint, not a Description.
>>
>> - 6.7.11.6.2 p2 "shall have the stateless attribute"
>> That seems a bit over-the-top. This attribute is an assertion by the
>> programmer to the compiler, so requiring that any called function has
>> the stateless attribute seems to hinder gradual adoption in a larger
>> codebase (where e.g. some third-party library function is known to be
>> stateless, but not (yet) annotated as such).
>>
>> - 6.7.11.6.3 p2 "are const qualified variables that may range over
>> the whole admissible set" This feels like "value" is missing
>> somewhere, e.g. "whose values may range over..." What's the
>> "admissible set" of function arguments? Using const-qualified
>> variables as function arguments doesn't do anything, because the
>> function parameter values are copies of those arguments anyway. Also,
>> I don't think the fact that something is const-qualified is the point
>> here, but the fact that no writes happen (you can choose not to write
>> to a non-const variable, too).
>>
>> - 6.3.2.1 p4 says "A function designator is an expression that has
>> function type." You say "A function designator identified by an
>> identifier f" What if I have an expression of function type that is
>> more than a simple identifier?
>>
>> - 6.7.11.6.3 p4 talks about "the" function designator, which is an
>> expression. However, all that is in view here is a function
>> definition. Where does the expression come from?
>>
>> - 6.7.11.6.4 p2 What does "objects for which the definition is met
>> during the call" mean? When do you "meet" a definition?
>>
>> Jens
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Link to this post: http://lists.isocpp.org/liaison/2021/03/0379.php
>
>
>
> Thanks
> Jens
>