Skip to content

CWG1463 extern "C" alias templates #1373

@jfbastien

Description

@jfbastien

Migrating from https://isocpp.org/files/papers/P1018R18.html#issues
CWG1463

Section: Clause 13.1 [temp.pre] Status: extension Submitter: Daveed Vandevoorde Date: 2011-08-19
Currently Clause 13.1 [temp.pre] paragraph 6 forbids any template from having C linkage. Should alias templates be exempt from this prohibition, since they do not have any linkage?

Additional note, April, 2013:

It was suggested that relaxing this restriction for alias templates could provide a way of addressing the long-standing lack of a way of specifying a language linkage for a dependent function type (see issue 13).

Rationale (April, 2013):

CWG felt that this suggested use of alias templates should be considered in a broader context and thus was more appropriate for EWG.

Currently 13 [temp] paragraph 4 forbids any template from having C linkage. Should alias templates be exempt from this prohibition, since they do not have any linkage?

Additional note, April, 2013: It was suggested (see messages 23364 through 23367) that relaxing this restriction for alias templates could provide a way of addressing the long-standing lack of a way of specifying a language linkage for a dependent function type (see issue 13). The priority was deleted to allow CWG to consider the implications of that potential application of the facility.

We should either have some way to express a dependent function type with C language linkage (and should accept 1555 below) or we should remove the notion that C language linkage (or not) is part of the function type at all. (Apparently some targets used it; are they still in use? EDG probably knows.)

Actively discussed on CWG reflector.

Davis’ interpretation of CWG discussion:

I don’t speak for Core, of course, but my (Evolutionary) thoughts are those given (last) in the message to which you replied: neither the wording nor the apparent intent of [temp.pre]/6’s restrictions on C linkage for templates make any sense. Since templates (and explicit specializations) can’t have C linkage of the name-mangling variety (which the standard calls language linkage of a (function) name) but can have C linkage of the calling-convention variety (which the standard calls language linkage of a (function) type), extern "C" should grant them the latter and not the former with no error. This has certain obvious applications involving C APIs with callbacks. (Put differently, CWG13 shouldn’t have been rejected; it appears to have gotten bogged down in questions of syntax, but we have an adequate syntactic workaround that we merely have to permit.)

CWG1463 asks for a (very) proper subset of the above: merely that extern "C" be allowed to apply to alias templates (claiming incorrectly that they have no name with linkage at all). I consider it more relevant (and more productive) to talk about whether entities have names with language linkage than with the ordinary kind.

The Core reflector discussion (which seems to have finished for the moment) also touched on the case where "the same" function template is declared with two different language linkages for its type, but the only relevant Evolution input there would be a decision to go the opposite way and forbid function templates from having types with C language linkage entirely. (They currently can, but it’s mostly or entirely useless.)

If (for CWG1555, also on your list) the rules about language linkage of (function) types are sufficiently relaxed, then CWG1463 may be moot (and my extension of it with it), but that seems unlikely given Hubert’s recent identification of a case where they matter.

Meeting: (notes 2020-04-15, notes 2020-10-22, also discussed in Rapperswil 2014) We agree that this is an issue. extern “C” on a template should only affect calling convention, and not the mangling. Davis and Hubert volunteer to write a paper. Unanimous consent.

Metadata

Metadata

Assignees

No one assigned

    Labels

    EWGEvolutionneeds-revisionPaper needs changes before it can proceed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions