11 May
2020
11 May
'20
2:32 a.m.
Interesting that Go had only what you call "typed typdefs" until we needed
to add "untyped typedefs" so we could provide aliasing for forwarding
declarations. And that necessity made me unhappy. But the short version: Go
went the other way with what "typedef" means.
-rob
On Mon, May 11, 2020 at 10:28 AM <scj(a)yaccman.com> wrote:
Following up on Rob's comment, I always took the
point of view that Dennis
owned the C description, and what he said goes. Not that I didn't make
suggestions that he accepted. One of the better ones (actually in B) was ^
for exclusive OR. One of the worse ones was the syntax for casts. We
looked at about 5 different ideas and hated all of them. And most of them
couldn't be easily compiled with Yacc. So I took the grammar for
declarations, removed the variable name, and voila, it expressed everything
we wanted in the way of semantics, had a simple rule of construction, and
we badly needed the functionality for the Interdata port. I quickly came
to hate it, though -- the casts we were using looked like a teletype threw
up in the middle of the code.
With respect to enums, there is a feature I've wanted for years: a typed
typedef. Saying typetdef int foo would make foo an integer, but if you
passed an ordinary int to something declared as foo it would be an error.
Even if it was an integer constant unless cast.
The amount of mechanism required to get that behavior from both C and C++
is horrible, so far as I know, although C++ has accreted so much stuff
maybe it's there now...
Steve
---
On 2020-04-24 19:54, Rob Pike wrote:
Another debate at the time was caused by a disagreement between pcc and cc
regarding enums: are they a type or just a way to declare constant? I
remember getting annoyed by pcc not letting me declare a constant with an
enum and use it as an int. I protested to scj and dmr and after some to-ing
and fro-ing Steve changed pcc to treat them as constants.
Not sure it was the right decision, but C desperately wanted a non-macro
way to define a constant. I'd probably argue the same way today. The real
lesson is how propinquity affects progress.
-rbo
On Sat, Apr 25, 2020 at 12:51 PM Rob Pike <robpike(a)gmail.com> wrote:
The ability to call a function pointer fp with the syntax fp() rather than
(*fp)() came rather late, I think at Bjarne's suggestion or example. Pretty
sure it was not in v7 C, as you observe.
Convenient though the shorthand may be, it always bothered me as
inconsistent and misleading. (I am pretty sure I used it sometimes
regardless.)
-rob
On Sat, Apr 25, 2020 at 12:48 PM Adam Thornton <athornton(a)gmail.com>
wrote:
On Apr 24, 2020, at 7:37 PM, Charles Anthony <charles.unix.pro(a)gmail.com>
wrote:
On Fri, Apr 24, 2020 at 7:00 PM Adam Thornton <athornton(a)gmail.com> wrote:
This doesn't like the function pointer.
$ cc -c choparg.c
choparg.c:11: Call of non-function
Perhaps:
(*fcn)(arg);
We have a winner!
Also, Kartik, dunno where it is on the net, but if you install a v7
system, /usr/src/cmd/c
Adam