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

[David Blaikie via cfe-dev]

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)?)

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.

- 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171116/e39070d0/attachment.html>