121–130 of 152 posts
Earlier quoted context omitted.
If a giant meteor took out WG14 we might get named arguments in C modify_string(.str=str, .options = { .toggle_case = true, .strip_whitespace = false });
I've wanted a similar thing for C++. Anyone know what the reasons have been for the language not adopting this?
Earlier quoted context omitted.
My understanding of the comment is that it’s in the context of saving an enumeration-object into a database. Like Typescript might (for example) represent enums as integers like 1, 2, 3... at runtime. What happens if you decide to store a “delivery status” enum in a database? You would just be saving a number into the database, which can be hard to understand. If it’s a string, then the value stored in the database i…
Yeah, one of the annoyances I have with using Enums, even in other languages, is that its serialised value isn't always obvious. Something like direction.NORTH could serialise into "NORTH" or some integer, depending on the language and the implementation. I like Typescript's union of string literals approach because its serialised value is never in question. I know exactly what "NORTH" serialises to.
Earlier quoted context omitted.
Sadly there is nothing that can tell you that you got those arguments backwards.
Point taken. But you can check the declaration of RaiseInvoice and see if the names match. If you had RaiseInvoice(false, true) then you really wouldn't know.
RaiseInvoice(/*taxInvoice*/ false, /*sendEmail*/ true)Folks, the headline is real bad and clickbaity, but I think the blog post is actually very, very correct in its basic premise.
But stating “don’t use booleans” is a terrible absolutist ideas that will lead to terrible code. Imagine a student reads it, takes it to heart, and starts creating dedicated enums for every logic branch in their code.
Earlier quoted context omitted.
Typescript is great for this. function operation(user: User, state: “active” | “inactive”): void Boom. Done. Enum defined. You want people to use enums? Remove all context switching from the definition process.
That’s the worst way to define enums. Now you have to make sure your codebase is using the same string literals everywhere and carry the potentially long type definition to every parameter, variable or function return type. And no, compile-time checks won’t cover 100% of cases.
This goes away in a language that allows arguments to name the parameters: fetch(accountId, history = true, details = false); However, I would be opposed if this mechanism is permitted to perturb the order of fixed arguments. If history is the third argument, rather than the second, it should error. I.e. "history = true" means "we are passing true as the second parameter, which we believe to be called 'history', on p…
Is this an example from some well-known compiled language? I work mostly in C++, and this is a feature I've wished for for a long time.
Earlier quoted context omitted.
That’s the worst way to define enums. Now you have to make sure your codebase is using the same string literals everywhere and carry the potentially long type definition to every parameter, variable or function return type. And no, compile-time checks won’t cover 100% of cases.
Obviously if this gets reused you need to put it in a central definition.
Otherwise, it becomes an absolute mess of “almost” defined correctly.
The assumption being that the language you are using does not have named parameters. Something all modern languages have, except, as usual, the ones the world is built on (JS, Java).
Named parameters are easy enough to mimic in JS using objects and the spread operation function foo({bar, baz}) { ... } foo({bar: 1, baz: false})
My ideal language would have function prototypes that look something like:
return_type function_name(parameter_name type (default_value) [constraints], ...)
Of course, doing this adds overhead to the developer at the time the code is written. Instead of just writing 'bool', you need to go into the header and define a new enum and decide what it and each of its entries will be named, and make sure that it is propagated up through any dependencies that will interact with that function and so on.
Frankly, that can be a lot more work - especially in a large legacy code base.
Sometimes just a simple Bool is easier.
You can think of booleans as a built-in, two-value enum that has a common semantic meaning. Use booleans if this is suitable for your purpose; it will be suitable for many. That said... this article feels like a bit of a strawman. Does anyone by default use three booleans in cases that are arechetypical enums?
> You can think of booleans as a built-in, two-value enum that has a common semantic meaning. I love it when a language's bool type is just a sum-type like the sum-types you define in user code, e.g. https://ocaml.org/manual/5.2/core.html#hevea_manual10 . It's an indicator of a language with good foundations.