3 ms·

Well yes I find these pretty insane. It's not ergonomic. It doesn't actually offer any safety. It has no integration with anything else. If I compare this to, f

Well yes I find these pretty insane. It's not ergonomic. It doesn't actually offer any safety. It has no integration with anything else. If I compare this to, for example, the rust Option, or Haskell's Maybe, it's not even funny how stark the difference is. And both of them are over the counter included. Especially the the safety is something I can't step over. I don't feel it offers anything substantial over just having the struct without these macros.

uecker 1y ago
Please spell out your criticism exactly. Where do you see an issue with ergonomics? What exactly miss on integration? The safety property for such a type is clear: not being able to access the value when it does not exist. It does this. But most importantly before I let you shift the goal post: this was not original criticism. You said "insane complexity"
- rowanG077 1y ago
  Bad ergonomics, no integration and safety are all thinks that lead to complexity you need to manage were you to actually use this macro. The macros themselves are simple. But I don't think it's wrong to say using the macros does introduce insane complexity. Such things are often the case in C. The language is simple. To write anything of substance you have to introduce, often high amounts of, complexity. 1. Ergonomics: Forcing the null sanitizer is quite a sledgehammer you often cannot, or don't want, to pay, You are forcing global behavior for something you really only want locally for this construct. A misuse of maybe_value is a crash where in other languages you have case/match and compile time errors. There is no type inference so you have to be explicit at every, single, line, that you really mean a maybe(int) or whatever. 2. Integration: No libraries uses this, meaning any usage is limited to your own code only. Requiring manual and error prone translation at every interface. 3. Safety: No check the null sanitizer is actually on. This is a huge footgun where someone thinks "I know I use this neat macro I saw here". And then of course not enabling the null sanitizer and everything breaks. So now for this to be safe it's not enough to understand the code. You need to check if the compile options are just right. This is especially insidious since this cannot be hidden in some object file where you make damn sure the sanitizer is on. the CONSUMER of this API must enable the sanitizer For these reason I would ban this macro in any code I have control over.
  - uecker 1y ago
    Ok, thanks. I still do not see where the complexity comes in. I also disagree with most your other points, e.g. that other libraries do not use it seems rather irrelevant. I am certainly not switching to another languages for this reason. Type inference works with auto in C23 (or __auto_type as an extension before), but if you mean the macros themselves, being explicit is a bit reason why I prefer C to other languages. For the sanitizer, this is a choice which makes sense to me. If it does not make sense for you, calling "abort()" explicitly instead of relying on the null sanitizer would be a trivial change. The null sanitizer is also certainly not a big sledgehammer. In fact, in the example in the post there is no sanitizer instrumentation left.

uecker 1y ago

Please spell out your criticism exactly. Where do you see an issue with ergonomics? What exactly miss on integration? The safety property for such a type is clear: not being able to access the value when it does not exist. It does this. But most importantly before I let you shift the goal post: this was not original criticism. You said "insane complexity"

rowanG077 1y ago
Bad ergonomics, no integration and safety are all thinks that lead to complexity you need to manage were you to actually use this macro. The macros themselves are simple. But I don't think it's wrong to say using the macros does introduce insane complexity. Such things are often the case in C. The language is simple. To write anything of substance you have to introduce, often high amounts of, complexity. 1. Ergonomics: Forcing the null sanitizer is quite a sledgehammer you often cannot, or don't want, to pay, You are forcing global behavior for something you really only want locally for this construct. A misuse of maybe_value is a crash where in other languages you have case/match and compile time errors. There is no type inference so you have to be explicit at every, single, line, that you really mean a maybe(int) or whatever. 2. Integration: No libraries uses this, meaning any usage is limited to your own code only. Requiring manual and error prone translation at every interface. 3. Safety: No check the null sanitizer is actually on. This is a huge footgun where someone thinks "I know I use this neat macro I saw here". And then of course not enabling the null sanitizer and everything breaks. So now for this to be safe it's not enough to understand the code. You need to check if the compile options are just right. This is especially insidious since this cannot be hidden in some object file where you make damn sure the sanitizer is on. the CONSUMER of this API must enable the sanitizer For these reason I would ban this macro in any code I have control over.
- uecker 1y ago
  Ok, thanks. I still do not see where the complexity comes in. I also disagree with most your other points, e.g. that other libraries do not use it seems rather irrelevant. I am certainly not switching to another languages for this reason. Type inference works with auto in C23 (or __auto_type as an extension before), but if you mean the macros themselves, being explicit is a bit reason why I prefer C to other languages. For the sanitizer, this is a choice which makes sense to me. If it does not make sense for you, calling "abort()" explicitly instead of relying on the null sanitizer would be a trivial change. The null sanitizer is also certainly not a big sledgehammer. In fact, in the example in the post there is no sanitizer instrumentation left.