From: 643-408-1753@kylheku.com
On 2025-10-10, David Brown wrote:
> On 10/10/2025 08:27, BGB wrote:
>> On 10/9/2025 10:59 PM, Keith Thompson wrote:
>>> bart writes:
>
>>>
>>>>> One merit is if code can be copy-pasted, but if one has to change
>>>>> all instances of:
>>>>> char *s0, *s1;
>>>>> To:
>>>>> char* s0, s1;
>>>>> Well, this is likely to get old, unless it still uses, or allows C
>>>>> style declaration syntax in this case.
>>>>
>>>> That one's been fixed (50 years late): you instead write:
>>>>
>>>> typeof(char*) s0, s1;
>>>>
>>>> But you will need an extension if it's not part of C23.
>>>
>>> Yes, that will work in C23, but it would never occur to me to
>>> write that. I'd just write `char *s0, *s1;` or, far more likely,
>>> define s0 and s1 on separate lines. Using typeof that way triggers
>>> my WTF filter.
>>>
>>
>> Agreed.
>>
>>
>>
>> I think it can be contrast with C# style syntax (with "unsafe") where
>> one would write:
>> char* s0, s1;
>
> Does C# treat s1 as "char*" in this case? That sounds like an
> extraordinarily bad design decision - having a syntax that is very like
> the dominant C syntax yet subtly different.
The detailed properties of C syntax do not have that much mind share
in the kind of development done in C# and its ilk.
Only a minority of developers within a minority moving between
C and C# would suffer from confusion.
>
> Issues like this have been "solved" for decades - in the sense that
> people who care about their code don't make mistakes from mixups of
> "char" and "char*" declarations. There are a dozen different ways to be
> sure it is not an issue. Simplest of all is a style rule - never
> declare identifiers of different types in the same declaration.
> have preferred that to be a rule baked into the language from the start,
> but we all have things we dislike about the C syntax.
But the C syntax lets us factor out a common, complex part of the type
between two declared entities into the stem, so that we then highlight
what is different between them, without using a typedef alias. And the
fact that they are in the declaration, shows they are related.
struct foo {
/* lotsa members */
} x[42], *px = x, px_end = x + 42;
I /think/ that Java goes further in that you can factor out array
derivation into the stem:
int[3] a[4], b; // don't quote me on it
But something occurs to me. typedef shouldn't be a storage class;
that is silly. typedef should be something you can derive in a
declarator. Then you could do this:
struct {
/* lotsa members */
} typedef(foo), x[42], *px = x, px_end = x + 42;
How about a two-argument variant of typedef for use in
any part of a declarator:
int typedef(typedef(*, ptr_t)foo[42], array_t);
This is just
int *foo[42];
in which the pointer to int is typedefed as ptr_t, the array of 42
of those as array_t, and foo is declared as an object of that
array type.
Maybe :typedef syntax could be better.
struct {
/* lotsa members */
} foo : typedef, x[42], *px = x, px_end = x + 42;
and
int *:typedef(ptr_t) foo[42]:typedef(array_t);
Same thing: when the pointer is derived via *, the :typedef(name) syntax
takes a snapshot of that type and stores it into the scope under that
typedef name. Same thing with :typedef(arg) after the array declarator.
:)
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
