David Brown <david.brown@hesbynett.no> writes:

> On 27/08/2023 20:18, Malcolm McLean wrote:

>> No. Denis Ritchie didn't like const.
>
> That may or may not be true - early C did not have const, but that is no
> evidence for saying he didn't like it.

Malcolm may have better sources (he does not cite them) but I suspect
the view that DMR did not like const comes from am essay he wrote to the
committee about type attributes in January of 1988[1].

A now defunct attribute (noalias -- an early attempt at restrict) was
his main target, but the draft definition of const was also unworkable.
Since the draft is not preserved (as far as I know) you have to work
backwards from the problems he describes and the changes he proposed to
see what's wrong, but it does sound broken.

However, he was prepared to say of const that is has

"two virtues: putting things in read-only memory, and expressing
interface restrictions"

which is, essentially, what const is now. The wording he objected to
was changed. Did DMR end up liking const? I don't think there is much
evidence either way, but the sematics, as it was eventually defined, had
what he considered to be some virtues.

He /really/ objected to the proposed noalias attribute. In the same
document he concludes "Noalias must go. This is non-negotiable." In
fact, let me quote more from the conclusion:

"Noalias must go. This is non-negotiable.

It must not be reworded, reformulated or reinvented. The draft's
description is badly flawed, but that is not the problem. The concept
is wrong from start to finish. It negates every brave promise X3J11
ever made about codifying existing practices, preserving the existing
body of code, and keeping (dare I say it?) `the spirit of C.'

Const has two virtues: putting things in read-only memory, and
expressing interface restrictions. For example, saying

char *strchr(const char *s, int c);

is a reasonable way of expressing that the routine cannot change the
object referred to by its first argument. I think that minor changes
in wording preserve the virtues, yet eliminate the contradictions in
the current scheme."

There follow 5 detailed changes that pretty much align const with what
it is today. So DMR's position on the final form of const would seem
to be that typical uses are reasonable and that its virtues have been
preserved.

And, in a salute to better days, I note that DMR posted the whole thing
on comp.lang.c (nntp:7753@alice.UUCP).

[1] https://www.lysator.liu.se/c/dmr-on-noalias.html

--
Ben.

On Monday, 28 August 2023 at 21:39:42 UTC+1, David Brown wrote:
> On 28/08/2023 21:31, Malcolm McLean wrote:
> > On Monday, 28 August 2023 at 18:40:26 UTC+1, David Brown wrote:
> >> On 28/08/2023 18:35, Kaz Kylheku wrote:
> >>> On 2023-08-28, David Brown <david...@hesbynett.no> wrote:
> >>
> >>>> This means that in at least some cases, the use of continuous text was
> >>>> motivated by factors that outweighed legibility - perhaps costs, perhaps
> >>>> intentionally making the text harder to read.
> >>>
> >>> Like, maybe, keeping the illiterate rabble illiterate, maintaining the
> >>> status quo that only a tiny elite can read and write?
> >>>
> >> Yes. Writing without spaces isn't much harder than writing with spaces,
> >> but reading it is a lot harder. As a member of the elite, you don't
> >> want reading to be easier for others.
> >>
> >> Even within the elite classes, your ability to read unspaced texts
> >> quickly (or, more often, your ability to afford a scribe who could read
> >> it) was a status symbol. It was like serving larks' tongues at dinner -
> >> you don't do it because they are tasty or nutritious, you do it because
> >> they are expensive.
> >>
> >> I don't think anyone can say how much of an influence such reasons were,
> >> but it is certainly one of several reasons given by historians.
> >>
> > And then in the next paragraph, the same people claim that spaces were
> > omitted to save expensive parchment.
> Yes. Does it surprise you that there could be several reasons for
> something? Or that different people might have different reasons? Or
> that historians might have different theories?
>
To simultaneously argue that it was luxury consumption - deliberately making
text hard to read to force one to employ a more expensive scribe and therefore
flaunt one's wealth, and it was designed to save parchment is obviously self-
contradictory.
Since we know that parchment was expensive, and omiiting spaces obviously
saved parchment, it is entirely reasonable to suggest that this was a factor.
However most people who were interested in books in the ancient world were
not short of money.
>
> > You don't deliberately make things difficult for yourself. These suggestions
> > are all most implausible.
> They are all far more plausible than thinking it was easy to read.
>
No, not at all. People read it for two thousand years. It's entirely plausible
that it wasn't difficult, just not as easy as text with spaces.
>
> > We don't really know why the Greeks used scriptio continua whilst the Jews
> > did not. We do know that they did.
> Agreed. But we know some things that were not the reason for it. They
> did not omit spaces to make the writing more legible. That's a starting
> point at least.
>
The spaces weren't invented. The Jews had them. But the Greeks were reluctant
to take ideas from the Jews. The codex wasn't invented either until the first
century, but it's a lot easier to use than a scroll. However scrolls are not
extraordinarily difficult to use.
As I said, very early Greek texts and Latin texts before about 100 BC used dots
to separate words. These were later omitted. The motive for that may well have
been to improve legibility. Because spaces between words do make text easier
to read, it doesn't follow that symbols between words do the same.

On Monday, 28 August 2023 at 22:17:59 UTC+1, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
> > On 27/08/2023 20:18, Malcolm McLean wrote:
>
> >> No. Denis Ritchie didn't like const.
> >
> > That may or may not be true - early C did not have const, but that is no
> > evidence for saying he didn't like it.
>
> Malcolm may have better sources (he does not cite them) but I suspect
> the view that DMR did not like const comes from am essay he wrote to the
> committee about type attributes in January of 1988[1].
>
> There follow 5 detailed changes that pretty much align const with what
> it is today. So DMR's position on the final form of const would seem
> to be that typical uses are reasonable and that its virtues have been
> preserved.
>
> And, in a salute to better days, I note that DMR posted the whole thing
> on comp.lang.c (nntp:77...@alice.UUCP).
>
In the introduction, Ritchie says
"Let me begin by saying that I'm not convinced that even the pre-December qualifiers
(`const' and `volatile') carry their weight; I suspect that what they add to the cost of
learning and using the language is not repaid in greater expressiveness."

and then

"Volatile', in particular, is a frill for esoteric applications, and much better expressed
by other means. Its chief virtue is that nearly everyone can forget about it. `Const'
is simultaneously more useful and more obtrusive; you can't avoid learning about it,
because of its presence in the library interface. Nevertheless, I don't argue for the
extirpation of qualifiers, if only because it is too late."

So this doesn't sound like a man greatly enamoured of const. There's an element of
politiking - const is a fait accompli, and since his primary target is noalias, he can
throw a sop to the committee, which is that he will accept const, with modifications.

But essentially he shares my view that, yes, a rational argument can be made for
const and there are some situations where it is helpful. But these reasons are not
very strong, and it has disadvantages which haven't been acknowledged.

However the main problem with const as it was proposed was that casting a const
pointer to a non-const pointer was undefined, even if the const pointer was ultimately
derived from a pointer to mutable data.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> No. Denis Ritchie didn't like const.

Perhaps there's some confusion about an article Dennis Ritchie (note
spelling) made to this newsgroup in 1988, reproducing an essay he had
sent to X3J11.

He acknowledges that his discussion about const and volatile was based
on wording that was later changed. (He even advocated giving string
literals type `const char[]`.)

https://www.lysator.liu.se/c/dmr-on-noalias.html

(This is the article where he wrote "Noalias must go. This is
non-negotiable.".)

Malcolm, consider not speaking for Dennis Ritchie.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Scriptio Continua was used for about 2,000 years. So it's not
> difficult to read. This is a knock-down, simple, almost irrefutable
> point.

Since this point is "almost irrefutable", I suggest we all stop
wasting our time trying to refute it. Nobody other than Malcolm
takes it seriously, and Malcolm will not change his mind.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Scriptio Continua was used for about 2,000 years. So it's not
> difficult to read. This is a knock-down, simple, almost irrefutable
> point.

Since this point is "almost irrefutable", I suggest we all stop
wasting our time trying to refute it. Nobody other than Malcolm
takes it seriously, and Malcolm will not change his mind.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
> On 27/08/2023 22:56, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> And if one translation unit defined "void foo(int a, int b);", while
>>> another declared "void foo(int b, int a);" and used that with named
>>> parameters, you would not get the correct call.
>> True. So don't do that.
>
> That would boil down to undiagnosable undefined behaviour - and I'd
> rather avoid that. If there was a way to enforce checking here, it
> would be significantly better (IMHO). To me, avoiding mistakes is the
> most important justification for named parameters.

An implementation could warn about it, assuming it keep information
about parameter names in separately compiled translation units.

But we're talking about defining a function in one file, and then
writing an inconsistent declaration for that function in another file.
It's already easy to get undefined behavior that way -- and easy to
avoid it, by putting function declarations in headers that are included
by all source files that define or call the function.

> Since we can't do anything about currently legal declarations and
> definitions with different (or missing) parameter names, I think we
> want a new or modified syntax for the declaration and definition of
> functions that can use named parameters.

We can do something about current declarations and definitions. We can
define the behavior, and specify the few cases where the behavior is
undefined. If there are no parameter names in the visible declaration,
you can't use named arguments. If there are multiple compatible
declarations with differing parameter names (which is confusing and
easily avoidable), use the last one.

> I think that with this new
> type of declaration, the rules should be that a function should either
> be "static" and have at most one forward declaration, or non-static
> and have exactly one "extern" declaration in scope before it, and that
> the parameter names and styles (such as pointers or array parameter)
> match exactly. This would not force programmers to have declarations
> in a single header that is included by both the defining TU and TU's
> that use the function, but it would strongly encourage it. And it
> would make it a lot harder to get wrong.

How much harder does it have to be? A declaration that swaps the
parameter names would almost have to be deliberate, perhaps something
for the IOCCC.

> Since this would conflict with existing styles used in some code, I
> think we'd need a new syntax (or a new function attribute or
> qualifier). It's possible that compilers could have a flag to apply
> such checks by default (gcc has "-Wmissing-declarations
> -Wredundant-declarations", but no check on parameter names AFAIK), but
> that would be an implementation option, useful to some people and not
> others.

I don't think any of that is necessary, and I think it would make the
new feature more complicated, likely to the point that it would be
rejected.

Keep it simple. Parameters have names. For historical reasons, you can
redeclare a function with different parameter names, but it's a bad idea
unless you're doing it very carefully for the purpose of improving code
clarity.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> [named function arguments]
>
>>> The only way this can be sanely introduced into C with backward
>>> compatibility is if there is a separate way to introduce the
>>> parameter names used for named calling, like this:
>>>
>>> char *strcpy(const char * : dest, char * : src);
>>
>> Why not just declare
>> char *strcpy(const char *dest, char *src);
>> and use those names in calls, with a few simple rules for when there's
>> more than one visible declaration?
>
> Amusing that both of thesse declarations get the qualifiers
> wrong.

I am suitably amused.

char *strcpy(char *restrict dst, const char *restrict src);

(And we could discuss about how far "destination" and "source" should be
abbreviated.)

> I favor a different approach to this problem:
>
> static inline char *
> copy_to_from( char *to, const char *from ){
> return strcpy( to, from );
> }
>
> with no language changes needed. And people are still free to
> use the more concise form if they so desire.

But if we change the names used in the standard for strcpy's parameters,
there's no need for a wrapper function (with, in your approach, a name
that doesn't suggest that it operates on strings).

Your wrapper would be useful only if the language added named arguments,
yes? I'd expect that an edition of the standard that added named
arguments would also rework the argument names in the standard library.

Even without named arguments, I don't think "s1" and "s2" the best
choices for parameters of strcpy(). They're consistent with strcmp(),
but they don't need to be. It makes no semantic difference, but IMHO
the description would be a little clearer with more meaningful names.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 28/08/2023 21:37, Kaz Kylheku wrote:
> On 2023-08-28, Bart <bc@freeuk.com> wrote:
>> On 28/08/2023 19:01, David Brown wrote:
>>> On 28/08/2023 19:01, Bart wrote:
>>
>>>> Why is the standard moving backwards?
>>>
>>> What do you mean?
>>>
>>> C2x allows you to omit names for parameters you don't use in a function
>>> definition.  How is that "moving backwards" ?
>>
>> We want a stricter language moving forward and less of the crazy
>> flexibility of older versions.
>
> What?
>
>> What other missing bits of syntax can we assign some arbitrary meaning
>> to rather than being called out as obvious errors?
>>
>> How about, leaving out a function name in a definition, when that
>> function is not called?
>
> Yes, that is possible with this same feature:
>
>
> void foo_api_bar_impl(int arg, void (*)(char *))
> {
> // ...
> }
>
> This bar implementation of the foo API found that it didn't need to
> store or call the function pointer parameter, so it didn't name it.

My remark was about leaving out the main name of the function, like:

void (int arg, void (*)(char *)){}

If this function is never called, then it might stop some compilers
reporting that fact.

Although you will quickly find this is not practical: if you have a lot
of such anonymous functions, that you later need to call, you will no
longer know which is which.

Which helps to highlight another thing with missing parameter names; say
you end up with a function like this:

void F(int a, int, char* c, char*, int, int, int) {}

Later you decide that you do need to use one of those parameters, but
which one was it? That useful information imparted by the name doesn't
exist.

> In C++ implementations, this feature suppresses warnings about unused
> parameters. If it's not used, but not named, then there is nothing to
> complain about.
>
> C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
> prototype declaration, parameter names can be omitted.

That's not really surprising, since probably the same bit of grammar
covers both declaration and definition parameter lists.

And in the former, names can be added or omitted on a per-parameter basis.

So, an untidy bit of syntax, all-told.

(In the syntaxes I use, it is stricter:

* Parameters all have types only, no names (only in FFIs)
* Parameters all have types and names
* Parameters have names only (only in dynamic code)

You can't mix and match. And of course, a function definition must be
one of the last two. As is also necessary to make use of keyword
parameters and/or default values.

Detecting unused variables of any sort I consider the job of a tool
other than the compiler, although the compiler can make use of such info
internally to improve the code.)

> C++ just allowed that syntax in definitions, which looks like a
> miniscule extension that has as a palpable impact on usability.
>
> C programmers have wasted lines of code on things like
>
> void foo_api_bar_impl(int arg, void (*fn)(char *))
> {
> UNUSED(fn); // this project's own unused macro
> }

Excuse me, but that is just a problem with the compiler. You shouldn't
need to modify or annotation your code, or removed potentially useful
information, just to silence a warning.

I think if I had to do something on those lines, I would use parameter
names starting with '$'. Then no warnings are given; I don't need to
annotate; I can use a more consistent grammar rule; and I retain a
reminder of what the names for those parameters not currently refered to;

I could even use that parameter name later, with the '$', but it might
be simpler to delete that one character.

>>>> But this one is unusual: normally newer gcc tries to continue passing
>>>> legacy code that older versions passed. Now, it can be passing code
>>>> that older versions *failed*.
>>>
>>> And the problem with that is... what?  Nothing, as far as I can see.
>>
>> It was an error before for a good reason. Now somebody decided you need
>> to take away some redundancy so that they can declare unused parameters
>> without the compiler moaning about it.
>
> C++ has had this feature for decades. Adopting it into C improves the
> range of compatibility between the languages.

What was it used for in C++?

> Accidentally missing a name makes itself loudly heard when you use
> the name and it's not defined.
>
> You could have a bug whereby it is defined, but in an outer scope;
> that's too bad for you.

That's not a bug. It's called shadowing, a useful feature meaning you
can reuse identifiers in their own private scope, without needing to
have unique identifiers throughout a translation unit. This is not assembly!

> Since standard C doesn't have nested functions, that would have to be a
> clash between a intended/forgotten local and global, which indicates
> that you're using a local-like naming scheme for globals.

But gnu C has. Which itself leads to slightly inexplicable errors when
you forget the } at the end of a function, and the following 400
functions are assumed to be nested.

> If you think you will use the parameters, you will likely put in
> their names and live with the unused diagnostics which remind you
> to complete the work.

Sometimes I have a suite of functions which must all share the same
signature, as they accessed from a table of function pointers.

But the functions do different somewhat different tasks and may not use
all the parameters. I wouldn't be happy about those 200 or whatever
functions ending up with parameter lists looking like this:

(int a, int b, int c)
(int a, int, int)
(int a, int b, int)
(int, int, int c)

>> Yet an overzealous compiler might warn about an unused parameter name.
>
> This is not overzealous. Diagnosis of unused lexical variables uncovers
> bugs. You want this in any language with lexical scopes, and to be on by
> default.

So you run a tool to check that every so often, or use that compiler option.

> Code bombs when run:
>
> 4> [*3]
> ** expr-2:1: variable y is not defined
>
> Unused variables are code smell which can indicate an actual
> bug like: (defun add (x y) (+ x x)).

OK, so that's good. But here you want to use that parameter.

What happens what you really want to use only x, but it is necessary to
pass two (maybe it has to be a certain pattern); how do you indicate
that here?

Leave out y turns in into a one-parameter function; it needs to be two!

So it's trickier in a language without type annotations as place-holders.

>
> Sometimes unused variables are just crumbs left after refactoring;
> it's good to clean them out.
>
>> There must be better ways of shutting it up than deleting the name
>> completely. So, what was it again, when you decide to use it?
>
> If the option is available in the syntax, there is nothing better.

I mentioned a possibility above.

> All else being equal, subtracting a token to achieve a goal is
> better than adding more tokens.

You're also taking away what could be vital information needed to
restore the name, or deciding which parameter you restoring it to.

>> GCC Fail Pass
>> Clang Fail Warning
>> MSVC Fail Fail

> They are a newer dialect of C. Obviously, you can't use the feature
> if your code has to work with older compilers (that are not C++).

And yet, using the most recent versions of 3 major compilers at the time
of writing, one passes, one warns, one fails!

Talk about being equivocal. You'd think a C compiler would know whether
an input is valid C or not.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

[..ancient writing systems..]

Malcolm, will you please stop going on about this crap?
It has long since stopped being topical in this newsgroup.

scott@slp53.sl.home (Scott Lurndal) writes:

> I will use [underscore] in preference to CamelCase, which I dislike
> primarily because of the impact on my typing speed.

In most cases I find CamelCase harder to read than using
underscores, especially when using mono-spaced fonts.

scott@slp53.sl.home (Scott Lurndal) writes:

[...]

> Are you using the royal "we" here?

I think the narcissistic "we" is more likely.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
>> No. Denis Ritchie didn't like const. But to say "const is a bad
>> idea because Denis Ritchie didn't support it" is fallacious, though
>> obvioulsy Denis Ritchie almost certainly knows what he is talking
>> about, and obvioulsy the committee has shown their inferiority inm
>> many other ways. But you have to look at the arguments Ritchie
>> used, not just say "Ritchie says so, so it is".
>
> I am sorry, I am a bit lazy today and cannot be bothered to do web
> searches. What exactly are Ritchie's arguments against "const"?
>
> I cannot think of any, but I have heard some that lend support
> to having, and properly using, "const".

Current thinking in programming language design tends to favor
read-only being the default, with assignable variables needing
an explicit indicator.

I modestly suggest the keyword "prost" as a type qualifier to
mean modifiable.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[..regarding the naming of size_t..]

> And, in fact, I was actually thinking rhetorically -- how would
> I word it to tip the result? I was considering: "is size_t a
> sound engineering compromise or a dog's breakfast?".

STOP!

You're /both/ right!!!

The name size_t is a sound engineering compromise AND a dog's
breakfast.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [named function arguments]
>>
>>>> The only way this can be sanely introduced into C with backward
>>>> compatibility is if there is a separate way to introduce the
>>>> parameter names used for named calling, like this:
>>>>
>>>> char *strcpy(const char * : dest, char * : src);
>>>
>>> Why not just declare
>>> char *strcpy(const char *dest, char *src);
>>> and use those names in calls, with a few simple rules for when there's
>>> more than one visible declaration?
>>
>> I favor a different approach to this problem:
>>
>> static inline char *
>> copy_to_from( char *to, const char *from ){
>> return strcpy( to, from );
>> }
>>
>> with no language changes needed. And people are still free to
>> use the more concise form if they so desire.
>
> But if we change the names used in the standard for strcpy's parameters,

Part of the point of my approach is that it doesn't need any
changes to the C standard.

> there's no need for a wrapper function (with, in your approach, a name
> that doesn't suggest that it operates on strings).

That's incidental. It could be copy_string_to_from();

> Your wrapper would be useful only if the language added named arguments,
> yes?

Not at all, that's the point. The function name indicates where
the destination (to) and source (from) arguments go. There is
no reason a declaration has to use those names, or any names at
all, for the function parameters. All the information needed
is present in the name of the function.

> I'd expect that an edition of the standard that added named
> arguments would also rework the argument names in the standard library.

Part of the advantage of the approach I favor is it doesn't
need to wait for a new edition of the C standard. I think
there are lots of cases where simply adopting a coding style
obviates any need for new language features.

> Even without named arguments, I don't think "s1" and "s2" the best
> choices for parameters of strcpy(). They're consistent with strcmp(),
> but they don't need to be. It makes no semantic difference, but IMHO
> the description would be a little clearer with more meaningful names.

In the context of the C standard, and especially for strcpy(), I
don't see anything wrong with s1 and s2. Moreover using s1 and s2
means there won't be any bike-shedding arguments about what the
names should be.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> [named function arguments]
>>>
>>>>> The only way this can be sanely introduced into C with backward
>>>>> compatibility is if there is a separate way to introduce the
>>>>> parameter names used for named calling, like this:
>>>>>
>>>>> char *strcpy(const char * : dest, char * : src);
>>>>
>>>> Why not just declare
>>>> char *strcpy(const char *dest, char *src);
>>>> and use those names in calls, with a few simple rules for when there's
>>>> more than one visible declaration?
>>>
>>> I favor a different approach to this problem:
>>>
>>> static inline char *
>>> copy_to_from( char *to, const char *from ){
>>> return strcpy( to, from );
>>> }
>>>
>>> with no language changes needed. And people are still free to
>>> use the more concise form if they so desire.
>>
>> But if we change the names used in the standard for strcpy's parameters,
>
> Part of the point of my approach is that it doesn't need any
> changes to the C standard.

Ah, I misunderstood your point.

This subthread has been about how named arguments should be implemented.
You're saying that if named arguments *aren't* added as a new feature,
providing a wrapper function whose name indicates meanings of the
parameters

I would never bother to write or use the wrapper function you suggest.
I deal with the potential ambiguity in the parameters of strcpy() by
remembering that the destination is first, analagous to an assignment.
I speculate that you do the same.

I'm sympathetic to arguments that named arguments shouldn't be added to
C because it would be too complex. I personally think it would be a
worthwhile change, but I can certainly live without it. But if it were
added, it could be very useful in writing more legible code. strcpy()
is just one example. More compelling examples are functions that take
one or more bool arguments. I've used languages (Ada, Python) with
named arguments, and found the feature very useful.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-08-28, Bart <bc@freeuk.com> wrote:
> On 28/08/2023 21:37, Kaz Kylheku wrote:
>> On 2023-08-28, Bart <bc@freeuk.com> wrote:
>>> On 28/08/2023 19:01, David Brown wrote:
>>>> On 28/08/2023 19:01, Bart wrote:
>>>
>>>>> Why is the standard moving backwards?
>>>>
>>>> What do you mean?
>>>>
>>>> C2x allows you to omit names for parameters you don't use in a function
>>>> definition.  How is that "moving backwards" ?
>>>
>>> We want a stricter language moving forward and less of the crazy
>>> flexibility of older versions.
>>
>> What?
>>
>>> What other missing bits of syntax can we assign some arbitrary meaning
>>> to rather than being called out as obvious errors?
>>>
>>> How about, leaving out a function name in a definition, when that
>>> function is not called?
>>
>> Yes, that is possible with this same feature:
>>
>>
>> void foo_api_bar_impl(int arg, void (*)(char *))
>> {
>> // ...
>> }
>>
>> This bar implementation of the foo API found that it didn't need to
>> store or call the function pointer parameter, so it didn't name it.
>
> My remark was about leaving out the main name of the function, like:
>
> void (int arg, void (*)(char *)){}
>
> If this function is never called, then it might stop some compilers
> reporting that fact.

In fact we can write, equivalently:

void foo_api_bar_impl(int arg, void (char *))
// ^ no name

Leaving out the top-level name of a function is interesting, but
I don't see how it makes sense.

The reason we would likee to remove the parameter name is that
the parameter must continue to exist; it itself cannot be removed, since
the calls to the functions are passing it an argument.

If a function is not called from anywhere, we just remove it.

We can't always edit calls to a function to remove an argument.
Sometimes in code we don't control, and possibly in callback interfaces
with multiple implementations, where you can't/don't want to remove a
parameter even if you do control everything.

> Although you will quickly find this is not practical: if you have a lot
> of such anonymous functions, that you later need to call, you will no
> longer know which is which.
>
> Which helps to highlight another thing with missing parameter names; say
> you end up with a function like this:
>
> void F(int a, int, char* c, char*, int, int, int) {}

If this is registered as a callback somewhere, we find that line:

register_foo_callback(F, whatever);

Then we look at the definitition of that to understand what the
arguments mean.

F could also have a declaration where the parameters are named,
and the could be documented in a block comment there.
>
>> In C++ implementations, this feature suppresses warnings about unused
>> parameters. If it's not used, but not named, then there is nothing to
>> complain about.
>>
>> C++ based this on *existing* syntax in ANSI C: namely that in an ANSI C
>> prototype declaration, parameter names can be omitted.
>
> That's not really surprising, since probably the same bit of grammar
> covers both declaration and definition parameter lists.
>
> And in the former, names can be added or omitted on a per-parameter basis.
>
> So, an untidy bit of syntax, all-told.

It's untidy; only, the viable alternatives are worse.

> (In the syntaxes I use, it is stricter:
> * Parameters all have types only, no names (only in FFIs)
> * Parameters all have types and names
> * Parameters have names only (only in dynamic code)

That's very nice, but you've not convinced the world to standardize
on those syntaxes, and develop an entire free operating system,
and multitude of tools and applications, and so on.

For now we are stuck with what we have.

People working on replacements are by and large making the programming
experience worse. More complicated, more convoluted, more siloed into
their little necks of the woods.

Make me a concrete recommendation on how to code, and what with.

In my work and side projects, I target 32 and 64 bit ARM boards,
desktop GNU/Linuxes (Ubuntu, Debian, Nix, Guix, ...), MacOS, Solaris,
Android.

> Detecting unused variables of any sort I consider the job of a tool
> other than the compiler, although the compiler can make use of such info
> internally to improve the code.)

So you like tools other than the compiler eh? Oh, except when they
are called "make" for building stuff, and whatnot; then tools not
in the compiler are bad.

If a compiler just improves the code (e.g. eliminatees dead code)
but doesn't remark on unusd variables, it's being only halfway helfpul.

This is really a "low hanging fruit" diagnosis; it has a decent payoff
relative to implementation cost and difficulty.

>> C++ just allowed that syntax in definitions, which looks like a
>> miniscule extension that has as a palpable impact on usability.
>>
>> C programmers have wasted lines of code on things like
>>
>> void foo_api_bar_impl(int arg, void (*fn)(char *))
>> {
>> UNUSED(fn); // this project's own unused macro
>> }
>
> Excuse me, but that is just a problem with the compiler. You shouldn't
> need to modify or annotation your code, or removed potentially useful
> information, just to silence a warning.

Yet, someone hit upon that idea, and people liked it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 29/08/2023 00:49, Tim Rentsch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>> [named function arguments]
>>>
>>>>> The only way this can be sanely introduced into C with backward
>>>>> compatibility is if there is a separate way to introduce the
>>>>> parameter names used for named calling, like this:
>>>>>
>>>>> char *strcpy(const char * : dest, char * : src);
>>>>
>>>> Why not just declare
>>>> char *strcpy(const char *dest, char *src);
>>>> and use those names in calls, with a few simple rules for when there's
>>>> more than one visible declaration?
>>>
>>> I favor a different approach to this problem:
>>>
>>> static inline char *
>>> copy_to_from( char *to, const char *from ){
>>> return strcpy( to, from );
>>> }
>>>
>>> with no language changes needed. And people are still free to
>>> use the more concise form if they so desire.
>>
>> But if we change the names used in the standard for strcpy's parameters,
>
> Part of the point of my approach is that it doesn't need any
> changes to the C standard.
>
>> there's no need for a wrapper function (with, in your approach, a name
>> that doesn't suggest that it operates on strings).
>
> That's incidental. It could be copy_string_to_from();
>
>> Your wrapper would be useful only if the language added named arguments,
>> yes?
>
> Not at all, that's the point. The function name indicates where
> the destination (to) and source (from) arguments go. There is
> no reason a declaration has to use those names, or any names at
> all, for the function parameters. All the information needed
> is present in the name of the function.

So you've just moving the parameter names to the name of the function.

You're now back to remembering the order, by having to remember the name
of the function.

The parts of the name for the N arguments, and the N arguments
themselves are now disjoint.

You don't have the choice of using a short function name and using
non-keyword parameters. You might want to do that if you can remember
which way around the strcpy arguments go.

You can't apply the scheme to existing functions that are exported using
a certain name from their libraries; you'd have to write wrapper functions.

And it's not really scalable to many arguments. It also would not allow
for optional arguments, or allowing for your own choice of argument order.

>> I'd expect that an edition of the standard that added named
>> arguments would also rework the argument names in the standard library.
>
> Part of the advantage of the approach I favor is it doesn't
> need to wait for a new edition of the C standard.

But then things will never change.

On 2023-08-29, Bart <bc@freeuk.com> wrote:
> On 29/08/2023 00:49, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Part of the advantage of the approach I favor is it doesn't
>> need to wait for a new edition of the C standard.
>
> But then things will never change.

But when they do change, you will try things on three random compilers,
one of which speaks its own native dialect by default, one which has
that new standard and a third which doesn't and then proclaim that the
language is in chaos; will the real C language stand up?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 29/08/2023 01:07, Tim Rentsch wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> I will use [underscore] in preference to CamelCase, which I dislike
>> primarily because of the impact on my typing speed.
>
> In most cases I find CamelCase harder to read than using
> underscores, especially when using mono-spaced fonts.

I used to use camelCase for most of my identifiers - now I find I am
using underscores much more, precisely because I find it easier to read.
I strongly suspect it is age-related - camelCase was more appealing
when my eyes were younger.

On Tuesday, 29 August 2023 at 01:23:52 UTC+1, Kaz Kylheku wrote:
>
> If a compiler just improves the code (e.g. eliminatees dead code)
> but doesn't remark on unusd variables, it's being only halfway helfpul.
>
> This is really a "low hanging fruit" diagnosis; it has a decent payoff
> relative to implementation cost and difficulty.
>
The problem is that people have a hysterical attitude to warnings, and
that occasionally, not so often, but not so infrequently either, there is
a legitimate need for an unused variable.
The obvious case is an unused parameter which is necessary to pass
the function indirectly, because other functions called through the same
function pointer do use the parameter.

On 29/08/2023 02:22, Kaz Kylheku wrote:
> On 2023-08-29, Bart <bc@freeuk.com> wrote:
>> On 29/08/2023 00:49, Tim Rentsch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Part of the advantage of the approach I favor is it doesn't
>>> need to wait for a new edition of the C standard.
>>
>> But then things will never change.
>
> But when they do change, you will try things on three random compilers,
> one of which speaks its own native dialect by default, one which has
> that new standard and a third which doesn't and then proclaim that the
> language is in chaos; will the real C language stand up?
>

Here's an example of people being afraid of change:

Most C compilers accept '$' within identifiers. I find that useful as a
more visually distinct 'special' character than '_' which already has
lots of official meanings.

The exceptions had been lcc-win32 (but years ago), where '$' could only
be used at certain places in a name.

And in Tiny C, until version 0.9.27, when it only worked if you gave
this ridiculous option:

-fdollars-in-identifiers

Tiny C isn't the most conforming compiler around; what are they actually
afraid of by just allowing it anyway?

There is always something. Wasn't that half the point of 'make' and
'configure'?

Now, maybe C doesn't officially sanction the use of '$', in which case
why do most compilers accept it?

gcc 13.2.0 will reject it using '-std=c89 -Wpedantic', and accept it if
anything else is used, but n1570.pdf (C11 draft) doesn't specifically
mention it.

So is '$' allowed or not? Can I safely use it with any compiler apart
from Tiny C? I don't know.

(I use '$' extensively in machine-generated code.)

On 29/08/2023 02:36, Bart wrote:
> On 29/08/2023 00:49, Tim Rentsch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>> [named function arguments]
>>>>
>>>>>> The only way this can be sanely introduced into C with backward
>>>>>> compatibility is if there is a separate way to introduce the
>>>>>> parameter names used for named calling, like this:
>>>>>>
>>>>>>    char *strcpy(const char * : dest, char * : src);
>>>>>
>>>>> Why not just declare
>>>>>      char *strcpy(const char *dest, char *src);
>>>>> and use those names in calls, with a few simple rules for when there's
>>>>> more than one visible declaration?
>>>>
>>>> I favor a different approach to this problem:
>>>>
>>>>      static inline char *
>>>>      copy_to_from( char *to, const char *from ){
>>>>          return  strcpy( to, from );
>>>>      }
>>>>
>>>> with no language changes needed.  And people are still free to
>>>> use the more concise form if they so desire.
>>>
>>> But if we change the names used in the standard for strcpy's parameters,
>>
>> Part of the point of my approach is that it doesn't need any
>> changes to the C standard.
>>
>>> there's no need for a wrapper function (with, in your approach, a name
>>> that doesn't suggest that it operates on strings).
>>
>> That's incidental.  It could be copy_string_to_from();
>>
>>> Your wrapper would be useful only if the language added named arguments,
>>> yes?
>>
>> Not at all, that's the point.  The function name indicates where
>> the destination (to) and source (from) arguments go.  There is
>> no reason a declaration has to use those names, or any names at
>> all, for the function parameters.  All the information needed
>> is present in the name of the function.
>
> So you've just moving the parameter names to the name of the function.
>
> You're now back to remembering the order, by having to remember the name
> of the function.
>

While you still need to remember things, it does make it harder to get
the order wrong when writing the code or for someone else reading the code.

> The parts of the name for the N arguments, and the N arguments
> themselves are now disjoint.
>
> You don't have the choice of using a short function name and using
> non-keyword parameters. You might want to do that if you can remember
> which way around the strcpy arguments go.
>
> You can't apply the scheme to existing functions that are exported using
> a certain name from their libraries; you'd have to write wrapper functions.
>
> And it's not really scalable to many arguments. It also would not allow
> for optional arguments, or allowing for your own choice of argument order.
>

I agree with all these points.

>
>>> I'd expect that an edition of the standard that added named
>>> arguments would also rework the argument names in the standard library.
>>
>> Part of the advantage of the approach I favor is it doesn't
>> need to wait for a new edition of the C standard.
>
> But then things will never change.
>
>

On Tuesday, 29 August 2023 at 10:40:53 UTC+1, Bart wrote:
> On 29/08/2023 02:22, Kaz Kylheku wrote:
> > On 2023-08-29, Bart <b...@freeuk.com> wrote:
> >> On 29/08/2023 00:49, Tim Rentsch wrote:
> >>> Keith Thompson <Keith.S.T...@gmail.com> writes:
> >>> Part of the advantage of the approach I favor is it doesn't
> >>> need to wait for a new edition of the C standard.
> >>
> >> But then things will never change.
> >
> > But when they do change, you will try things on three random compilers,
> > one of which speaks its own native dialect by default, one which has
> > that new standard and a third which doesn't and then proclaim that the
> > language is in chaos; will the real C language stand up?
> >
> Here's an example of people being afraid of change:
>
> Most C compilers accept '$' within identifiers. I find that useful as a
> more visually distinct 'special' character than '_' which already has
> lots of official meanings.
>
> The exceptions had been lcc-win32 (but years ago), where '$' could only
> be used at certain places in a name.
>

> Now, maybe C doesn't officially sanction the use of '$', in which case
> why do most compilers accept it?
>
Off-label use. If dollar signs are not allowed in identifiers in valid C programs,
but still accepted by the compiler, then the dollar sign becomes a symbol
which can be used, but not in C programs which are passed to someone else.
>
> (I use '$' extensively in machine-generated code.)
>
Exactly. Prefixing everything with a dollar sign is a good way of making your
machine-generated identifier match an identifier entered by the user, whilst
avoiding any possibility of a name clash.

Bart <bc@freeuk.com> writes:
[...]
> Now, maybe C doesn't officially sanction the use of '$', in which case
> why do most compilers accept it?
>
> gcc 13.2.0 will reject it using '-std=c89 -Wpedantic', and accept it
> if anything else is used, but n1570.pdf (C11 draft) doesn't
> specifically mention it.

In C89/C90, the syntax for an identifier allowed only the 52 uppercase
and lowercase Latin letters, underscores, and decimal digits.

C99 added universal-character-names and "other implementation-defined
characters".

So a conforming C99 or later compiler may or may not accept '$' in
identifiers. A conforming C90 compiler cannot.

(You saw that the gcc's behavior changed between "-std=c89 -Wpedantic"
and "-std=c99 -Wpedantic". It never occurred to you to check the C99
standard or the N1256 draft to see if the syntax of an identifier had
changed, did it?)

> So is '$' allowed or not? Can I safely use it with any compiler apart
> from Tiny C? I don't know.

See above.

> (I use '$' extensively in machine-generated code.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */