Re: question about linker

On 29/11/2024 12:28, Michael S wrote:

On Fri, 29 Nov 2024 11:04:16 +0000
Bart <bc@freeuk.com> wrote:
 

>
My original point was trying to address why 'const' as used in C
might be confusing. I was trying to compare how non-mutable variables
are designated in other languages. There it's a keyword that is part
of the declaration syntax, not the type syntax.
>

 I don't see your point.
How 'mut' in Rust is different from 'const' in C except for having
opposit polarity?
How 'readonly' in C# is different from 'const' in C?

I'm not familiar enough with those languages. Can mut or readonly be used multiple times within a single type specification? Can they be used in a context where no identifier is involved?
If so then they work like C's const does.
(My own attempts at 'readonly' used keywords that applied to definitions only, not to types:
   const [T] a = x            # x must be compile-time expr
   let    T  b := y           # runtime y but b can't be reassigned
   [var]  T  c [:= z]         # normal fully mutable variable
   static T  d  = w           # compile/load-time expr
I've dropped support for explicit 'let'; it tends to be used internally for implicit assign-once variables like loop indices; or fully readonly data like tables.)

 

I suggested that C is confusing because 'const' looks as though it's
like the former, but it's part of the latter. Which also means you
can have multiple 'const' in a declaration (putting asided repeated
'consts').
>

IMHO, any way to mix more than one 'modifier' (not in C standard
meaning of the word, but in more general meaning) is potentially
confusing. It does not matter whether modifier is 'const' or '*' or []
or ().

Constructing an abitrary type specification by chaining together 'modifiers' is not confusing by itself:
   Pointer to array 10 of const pointer to int x
   x: Pointer to array 10 of const pointer to int
It IS confusing the way C does it, because:
* It breaks it up into a base-type ...
* ... plus modifiers that go before any identifier ...
* ... plus modifiers that go after the identifier
* It allows a list of variable names in the same declaration to each
   have their own modifiers, so each can be a totally different type
* This means the type of a variable in a list can be split up into three
   disjoint parts
* It has 'const' that can go before OR after a basic type, or after
   a modifier that goes before an identifier, but not before or after a
   modifier that goes after an identifier (so no const array/function)
* The 'root' of the type, what would go on the left if expressed in
   LTR form, is somewhere in the middle of each typespec, starting
   near the identifier ...
* ... except that often there is no identifier, then you have to apply
   an algorithm to figure out what it means
* There are precedence rules which means often having to use parentheses
   to get the typespec that you want:  T*A[] is different from T(*A)[].
Apart from these minor points, typespecs in C are simple!
But if C types were LTR, and not split up, then figuring out whether the variable you're declaring was readonly is easy: there would be 'const' on the extreme left.
(I would also impose a rule that a 'const' on the left could not appear within a typedef, only at the point the type is used.)