| |
![Carl Sturtivant's Gravatar profile Gravatar of Carl Sturtivant](//www.gravatar.com/avatar/208ac6a7ffb3b20d8b6d3d62d567b554?d=identicon&s=32) | Posted by Carl Sturtivant in reply to Nick Treleaven | Permalink Reply |
|
Carl Sturtivant ![Carl Sturtivant's Gravatar profile Gravatar of Carl Sturtivant](//www.gravatar.com/avatar/208ac6a7ffb3b20d8b6d3d62d567b554?d=identicon&s=80)
Posted in reply to Nick Treleaven
| On Monday, 1 April 2024 at 18:28:16 UTC, Nick Treleaven wrote:
> On Sunday, 31 March 2024 at 23:05:44 UTC, Carl Sturtivant wrote:
> > Yes, it's not possible to instantiate a function type.
But with extern it seems the semantics is fine as a function is not being instantiated. It is merely associating a name with a type: in what sense is this instantiation in any reasonable way?
Yes there is no instantiation for extern. But what would be the use of allowing an extern function type instance, when there's no way to instantiate it?
-
For compile time work that uses the name but not the function it nominally refers to. That's what I wanted it for: ParameterIdentifierTuple might actually work on that.
-
In fact the definition might refer to a function defined in another module, for example brought in by ImportC. It's an alternative way of writing the signature of an external function. Why rule it out when it is reasonable?
The first could also work with an explicitly uninstantiated function, as in enum FUNCTYPE f = void; hence my second attempt above.
As long as there are compile-time actions that work on functions but not their types, this would be a way to work around that.
|