[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 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


> 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/20171115/54f4d160/attachment.html>