Date: Tue, 22 Oct 2024 13:59:33 -0700
sorry, I meant [[=annotation]] there.
On Tue, Oct 22, 2024 at 1:57 PM Garrett Fleenor <kylegar_at_[hidden]> wrote:
> Does objective-c parse the @identifier "keywords" inside of C++
> attributes? could [[@function]] work like the proposed [[+annotation]]?
>
> On Tue, Oct 22, 2024 at 1:46 PM Herb Sutter via SG7 <sg7_at_[hidden]>
> wrote:
>
>> > FWIW, I like the `class(things...)` syntax. It doesn't require
>> innovation, is
>>
>> > straightforward, and free of obstacles.
>>
>>
>>
>> Thanks! Re obstacles: As Bengt asked, how would you generalize it to
>> functions? That's the part I'm having trouble seeing a clear path about,
>> unless we add something like `function(things...)` before every function
>> which seems cumbersome. That is,
>>
>>
>>
>> // these are consistent
>>
>> @interface class IFoo { ... };
>>
>> @pure double f(double, double) { ... }
>>
>>
>>
>> vs (I can live with)
>>
>>
>>
>> // these are consistent with
>>
>> class(interface) IFoo { ... };
>>
>> function(pure) double f(double, double) { ... }
>>
>>
>>
>> The #1 most important thing to me is that we design for consistency and
>> generality.
>>
>>
>>
>> As we do that, my #2 hope is that we please keep the function cases in
>> mind for (future) first-class treatment. We will need to expand reflection
>> and generation to everything, including functions and statements and
>> expressions (and variables, and possibly namespaces, aliases, …). Not all
>> of those start with a clear keyword like class types do.
>>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>
>
>
> --
> Garrett Fleenor
> (They/Them or He/Him)
>
On Tue, Oct 22, 2024 at 1:57 PM Garrett Fleenor <kylegar_at_[hidden]> wrote:
> Does objective-c parse the @identifier "keywords" inside of C++
> attributes? could [[@function]] work like the proposed [[+annotation]]?
>
> On Tue, Oct 22, 2024 at 1:46 PM Herb Sutter via SG7 <sg7_at_[hidden]>
> wrote:
>
>> > FWIW, I like the `class(things...)` syntax. It doesn't require
>> innovation, is
>>
>> > straightforward, and free of obstacles.
>>
>>
>>
>> Thanks! Re obstacles: As Bengt asked, how would you generalize it to
>> functions? That's the part I'm having trouble seeing a clear path about,
>> unless we add something like `function(things...)` before every function
>> which seems cumbersome. That is,
>>
>>
>>
>> // these are consistent
>>
>> @interface class IFoo { ... };
>>
>> @pure double f(double, double) { ... }
>>
>>
>>
>> vs (I can live with)
>>
>>
>>
>> // these are consistent with
>>
>> class(interface) IFoo { ... };
>>
>> function(pure) double f(double, double) { ... }
>>
>>
>>
>> The #1 most important thing to me is that we design for consistency and
>> generality.
>>
>>
>>
>> As we do that, my #2 hope is that we please keep the function cases in
>> mind for (future) first-class treatment. We will need to expand reflection
>> and generation to everything, including functions and statements and
>> expressions (and variables, and possibly namespaces, aliases, …). Not all
>> of those start with a clear keyword like class types do.
>>
>>
>> --
>> SG7 mailing list
>> SG7_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>>
>
>
> --
> Garrett Fleenor
> (They/Them or He/Him)
>
Received on 2024-10-22 20:59:47