[cfe-dev] [RFC] Attribute that can be used to instruct clang to pass and return non-trivial structs directly

[Richard Smith via cfe-dev]

On 16 November 2017 at 10:09, David Blaikie via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Wed, Nov 15, 2017 at 8:09 PM John McCall <rjmccall at apple.com> wrote:
>
>> On Nov 15, 2017, at 10:45 PM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>>
>>
>> On Wed, Nov 15, 2017 at 11:56 AM Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>>> On 15 November 2017 at 11:34, John McCall via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> On Nov 15, 2017, at 11:13 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>>> On Tue, Nov 14, 2017 at 12:13 PM John McCall via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> I don't think we'd thought about documenting this (additionally) in
>>>>> terms of precise edits to the standard, but that's not a bad idea.
>>>>>
>>>>
>>>> Wasn't there a Clang policy about language extensions that required
>>>> they be at least proposed for standardization? (I can't seem to find that
>>>> anymore, but I think Doug proposed it/wrote it up at some point)
>>>>
>>>> Maybe attributes don't fall under this policy? Not sure.
>>>>
>>>>
>>>> That's a very good question.  I remember us talking about that, but I
>>>> don't think it ever turned into a firm policy.
>>>>
>>>
>>> It's in a somewhat non-obvious place on the website: http://clang.llvm.
>>> org/get_involved.html
>>>
>>
>> Ah, thanks! I kept getting search results listing that page & figured it
>> was a false positive... I should've looked more closely.
>>
>> Sounds like (4) is the only sticky one - and I guess this would be partly
>> the C++ standards committee and the Itanium ABI group. (perhaps this is
>> worth a discussion/proposal on the latter - to avoid anything like the
>> abi_tag difficulties (which I only have a vague sense of)?)
>>
>>
>> I'm not quite sure what connection you're drawing here.  In this case, I
>> think (4) is satisfied because Apple is promising to maintain the feature,
>> as we will have internal clients that will rely on it — although it sounds
>> like enough other people are interested in it that that really won't be a
>> problem.
>>
>
> Ah, sorry, I didn't mean to refer to (4) in your list, but (4) in the list
> on "Contributing Extensions to Clang" here: http://clang.llvm.org/
> get_involved.html
>
> Which says fairly unambiguously: "the extension itself must have an
> active proposal and proponent within that committee and have a reasonable
> chance of acceptance. ... This criterion does not apply to all extensions,
> since some extensions fall outside of the realm of the standards bodies."
>
> It sounds like this bullet point could just be softened a little somehow
> to accommodate this situation?
>
> Or maybe it does apply & we should make a point of bringing it up to the
> Itanium ABI group?
>

I think it would make a lot of sense to talk about this extension in the
Itanium C++ ABI, in the same way we talk about the abi_tag attribute. (And
I would consider such documentation to be a prerequisite for using the
attribute in libc++, having learned from our experiences with abi_tag,
where we were on the other side of a vendor extension necessary for ABI
compatibility with a target's standard library.)


> (I think since the only surface area in C++ is an attribute, and C++ has
> syntax entirely designed for extensibility here, there's no immediate need
> to bring it up there - it'd barely be meaningful to standardize it since
> it's such an implementation detail, I'd guess... - though I suppose the
> contract is useful "this type doesn't care about where its bits are in
> memory" is probably a generically useful property to discuss in the C++
> standard, but easy to move from custom attribute to standard attribute, etc)
>

I actually think it would make some sense to standardize this. It's really
unfortunate that unique_ptr<T> imposes an unnecessary abstraction penalty,
and providing a way to avoid that seems very much in scope for
standardization to me. (It's also not unprecedented; at the previous
meeting EWG approved a [[no_unique_address]] attribute for providing the
EBO layout rules for data members).


> I think what you may be suggesting is that, if we're indeed going to
>> revise Clang's policy about features, we should include a codicil that
>> encourages people to seek standardization of any new Clang vendor
>> extensions when that's reasonably possible.  In practice, the committees
>> will not standardize the Clang feature, they'll standardize their own
>> hopefully-similar feature, but it's still useful to seek standardization.
>> This is closely related to Richard's point about trying to ensure that new
>> features don't drive fragmentation.
>>
>> Mostly I'm just want to make sure we hold ourselves to a similar standard
>> than we expect from everyone else - rather than using the rules as a way to
>> keep people out while not necessarily meeting the same bar ourselves. &
>> this seems like a good chance to reflect on the rules, see if they do/still
>> fit, etc. Sounds like they mostly do.
>>
>> Don't mean to bog anything down in bureaucracy or anything.
>>
>>
>> No, you're absolutely right to bring it up.
>>
>> Should I draft a revision to the policy?  Any other initial commentary
>> before I do?
>>
>> John.
>>
>>
>> - Dave
>>
>>
>>>
>>>
>>>> I think the important points about language features are:
>>>>
>>>> 1. We don't want to take a feature that we don't like the design of
>>>> unless we're forced to by a language standard.  We're allowed to be
>>>> opinionated about language design!  Required, even.
>>>>
>>>> 2. We don't want to take a feature that's poorly-specified (again,
>>>> unless we're forced to by a language standard :)).  The specification
>>>> doesn't have to be expressed in terms of precise edits to a standard —
>>>> among other things, this would often be really annoying, since a lot of
>>>> features are intended to apply in both C and C++, and they may have
>>>> implications for other extensions like ObjC/OpenMP/whatever  — but it
>>>> should be at a point where such edits are reasonably extrapolable.  I
>>>> wouldn't say that it needs to be something that we can imagine an actual
>>>> standards committee taking, since there are a lot of reasons a committee
>>>> might reject a feature that don't necessarily imply a lack of quality;
>>>> also, this would be rather inconsistent of us, since we've certainly taken
>>>> features in the past that I'm not sure have much chance of standardization.
>>>>
>>>> 3. We want to be very cautious about accepting new language syntax
>>>> because it could infringe on future language evolution.  This is one place
>>>> where attribute-only features have a substantial advantage.
>>>>
>>>> 4. We want major language features to be maintained.  The concern here
>>>> grows with the amount of code contributed and how tightly it needs to be
>>>> integrated with the rest of the compiler.  This is one of those area where
>>>> life is not really fair, because we can't realistically assume that any
>>>> single contributor is going to be able to commit to maintaining a feature
>>>> the same way that an organization can.  For example, I personally have a
>>>> long history of contributing to Clang, and I think the language designs
>>>> I've contributed have been relatively good — but if I proposed a language
>>>> feature on my own behalf, without any commitment from Apple or anyone else
>>>> to continue maintaining that contribution if e.g. I got hit by a bus, I'm
>>>> not sure it would be reasonable for the project to accept my proposal.
>>>>
>>>> And implicit in all of these is that the feature ought to be
>>>> "open-source" — if you're going to propose a novel, non-standard feature,
>>>> you need to be willing to accept feedback about both the specification and
>>>> its basic design, and it really shouldn't depend on anything proprietary
>>>> like a closed-source runtime library.  We're allowed as a project to be
>>>> opinionated about this sort of thing, too.
>>>>
>>>> But I think if we like the feature, and we like its specification, and
>>>> we don't think it infringes on language evolution, and we have strong
>>>> reason to think it's going to be maintained, we don't need to hew tightly
>>>> to a "no new features" mandate.
>>>>
>>>
>>> That seems essentially reasonable to me.  We also need to be cognizant
>>> of the possibility of fracturing the developer community if our extensions
>>> fundamentally change the way that code is written. (Which is not the same
>>> as saying we can't have such extensions, just that they need to be
>>> especially welll-considered, and we should have a very good reason if we're
>>> not attempting to standardize them. Clang's header modules support falls
>>> somewhat into this category.)
>>>
>>> Attribute-based features don't get an automatic pass, but by their
>>> nature they're much more likely to meet these criteria.
>>>
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171117/3e5bfe50/attachment.html>