Re: [PATCH] introduce attribute exalias

[Nathan Sidwell <nathan@acm.org>]

On 8/14/20 10:43 PM, Alexandre Oliva wrote:
> On Aug 14, 2020, Nathan Sidwell <nathan@acm.org> wrote:


> Since you don't seem to have liked 'aka' either, how about 'nickname',
> or 'nicknamed'?  A more convenient name to refer to an entity is exactly
> what this is about, eh?

I'm sorry, I think those are awful names.   They convey no intent.  C++ already 
has at least 2 'nickname' mechanisms:

using bob = ::foo::bar<bob::random_type,int>;
auto &bill = ::elsewhere::object<some_type>;

'alias' is also now a confusing term, because of the concept of object-aliasing.

The existing alias attribute is defined as:

 > The @code{alias} attribute causes the declaration to be emitted as an alias
 > for another symbol, which must have been previously declared with the same
 > type, and for variables, also the same size and alignment.  Declaring an alias
 > with a different type than the target is undefined and may be diagnosed.  As
 > an example, the following declarations:

I.e. it is creating a declaration that is aliased to some other symbol (which 
has to also be emitted by the same TU due to the usual elf-like object file 
semantics).  Notice it says nothing about emitting a *symbol*.

The new attribute is emitting a symbol that equates the declaration it is 
attached to (i.e. the other way round).

Its intent is to allow code written in another language to refer to this 
definition.  I imagine you'd commonly use the foreign language's mangling for 
the string provided.

If we spell it 'X', consider:

[[gnu::X ("other")]] int i;

Most commonly, the assembly emitted would contain:
	.globl other
	.equiv other, i

so, perhaps we should spell it 'equiv'?  That's using an existing term.

nathan

-- 
Nathan Sidwell