liese

Liese

@liese

[ləˈiːs]

Grad student in CS. Monotropic nerd who spends way too much time with computers (and books (and computer books)). Likes space.

log inask
mastodon
hachyderm.io/@liese
You must log in to comment.

in reply to @ThePhD's post:

liese
@liese

Congrats!! 🎉

...Supposing I've spotted one or more minor typos, is there a preferred way to communicate those to you, or would you (understandably) prefer to not look at this thing for a solid week?

login to reply
liese
@liese

Section 4.3:

There is no impact on exsiting code

"existing"?

A follow-on paper will be written to address generic selection as a whole will be written

sans one of the two the duplicate "will be written"s?

(I didn't see any more typos in the rest of the document, though I admittedly only skimmed the standardese in Section 6.)

login to reply
IttoOgami
@IttoOgami

Not wanting to sound to negatively, but do the presented use cases really warrant an extension of the language, adding a new keyword?

Variables of structure types with different names but same content? Just memcpy() them and be done with it. Want to make it somewhat nicer for your users? Provide them with a copy() or assign() macro.

Provided that all members of the respective structure types have the same alignment requirements (and they will, if its members are of the same type) then compiler added padding is nothing worry about.

In my book this is a case of complicating the language with too little benefit.

Well, at least one can do #define _Record to keep code like this compatible with earlier versions of the C standard, I guess…

login to reply
ThePhD
@ThePhD

This goes a bit beyond just making things easier to copy or assign. (That just happens to come along for the ride.) The 2 big parts here are allowing for easy macro generic programming:

#define result(T, E) struct lib_result_##T##E##_t { bool engaged; union { T value; E error; }; };

which fails when T is int* or unsigned char. _Record means you can omit the name entirely, and it will be unnamed, and it will be compatible with other uses without a forward typedef/declaration in every translation unit for each type you want to have.

The second is allowing well-defined compatibility rules within a source file. Being able to alias my_ptr_and_size_t with your_ptr_and_size_t means you can avoid spurious copies for what is effectively the same data.

login to reply
IttoOgami
@IttoOgami

Thank you for taking the time for this clarification! Yes I have noticed attempts by people to bring Rustʼs “Result” struct type to C.

I can see the potential value in that and agree that having the possibility of structural typing (instead of the current tag based approach) could be beneficial in certain scenarios.

That being said I do think that relying on C23ʼs attribute specifier sequences—instead of introducing a new keyword—would have been a better choice:

#define result(T, E) struct [[structural]] { bool engaged; union { T value; E error; }; };

(I realize that the “Any attribute token that is not supported by the implementation is ignored.” rule makes things a little bit more difficult, but that would then just result in a compile error… which competent programmers could take as a hint to use a newer compiler that's aware of what's going on.)

login to reply