Yes, but it is still quite limited: they are not yet supported as associated type in traits or in type aliases.
1,178 karma · joined February 20, 2017
TypeScript & Rust programmer. Researcher in distributed systems, CRDT, embedded systems.
Github: @Conaclos Bluesky: @Conaclos Biome: https://github.com/biomejs/biome GPG: http://pgp.mit.edu/pks/lookup?search=victorien+elvinger
Yes, but it is still quite limited: they are not yet supported as associated type in traits or in type aliases.
This is not so simple. Even in the FOSS community, some people are allergic to copyleft licenses. I usually choose a license based on the practice of a community. Also, if you make the choice of copy-left in a world or copy-free is king, you are just isolating yourself from others. Often in big projects, you cannot alone, and the decision of license is a collective one.
I prefer the idea of regulating this mess: enforcing that everyone who has contributed to the success of a project - directly or indirectly - gets paid. It looks more fair and is based on merit - which this society seems to value.
[0] https://www.lemonde.fr/international/article/2025/03/19/etat...
[0] https://borretti.me/article/second-class-references; [1] https://www.hylo-lang.org/
SHOULD include a zero byte
I guess it is expected to be at the end of the magic number to act as a null-termibated string? MUST include a byte sequence that is invalid UTF-8
I guess it is to differentiate a text file from a specific format? MUST include at least one byte with the high bit set
Any reason? [apply]
# Remove trailing whitespaces
whitespace = fix
[color "diff"]
whitespace = red reverse
[diff]
colorMovedWS = allow-indentation-change
[format]
pretty = fuller
[log]
date = iso
[pull]
ff = onlyIf we install LineageOS, should we worry about Google's firmware update? Then why bother with all these steps?
In this case, I could write this:
type Activation = "Active" | "Inactive";
const Activation = {
__proto__: null,
Active: "Active",
Inactive: "Inactive",
} as { [K in Activation]: K };
This completely hides `__proto__` and avoid using utility types like `Exclude`.Note that it is safe because TypeScript checks that the type assertion is valid. If I mistype a value, TypeScript will complain about the assertion.
type MyEnum = typeof MyEnum[keyof typeof MyEnum];
const MyEnum = {
A: 0,
B: 1,
} as const;
Unfortunately I found it still more verbose and less intuitive than: enum MyEnum {
A = 0,
B = 1,
}
TypeScript enum are also more type-safe than regular union types because they are "nominally typed": values from one enum are not assignable to a variable with a distinct enum type.This is why I'm still using TypeScript enum, even if I really dislike the generated code and the provided features (enum extensions, value bindings `MyEnum[0] == 0`).
Also, some bundlers such as ESbuil are able to inline some TypeScript enum. This makes TypeScript enum superior on this regard.
In a parallel world, I could like the latter to be a syntaxic sugar to the former. There were some discussions [1] for adopting a new syntax like:
const MyEnum = {
A: 0,
A: 1,
} as enum;
[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...I am a bit skeptical about this, because this requires a jj daemon?
We have recently published a new research paper on replicating SQLite [1] in a local-first manner. We think it goes a step closer to that goal.