I see a lot of comments about how it is some sort of an unforeseen second-order consequence. But it isn't. If you want to have no tracking, you write a law that nans tracking. If you write a law about mandatory notifications, bombardment of notifications is the most direct consequence one can imagine.

Yes, that very much is an example of the law being badly written.

"Prior to giving consent, the data subject shall be informed thereof."

Means there must be some sort of a cookie notification (which could of course take a small space of the screen, but still).

The existence of this notification makes it easier to initially give consent. If withdrawing later is to be as easy, the notification must never disappear.

So you want users to be tracked without consent? I don't.

  struct S {
    int A;
    int B = A;
    int C;
  };

  int i = 0;
  S s = {.C = i++, .A = ++i};

What would you expect code like this to do?

The only useful solution for C++ would be to let the compiler reorder the initialization in declaration order, e.g. first A, then B, then C.

This would still be a lot better for 99% of real world use cases than requiring the programmer to manually place the items in declaration order.

This would be a big footgun though. That already happens for initialising class members in constructors and it's enough of a footgun that compilers have a warning to tell you if your initialisation order is different to the declaration order.

Doesn't the same footgun apply to function call arguments which are evaluated in an unspecified order?

    f(a++, b++)

That footgun doesn't seem to have very much impact in the real world that I've seen. Largely because people do not write complex expressions like that anymore. Since we already mostly avoid such expressions, we may as well take the benefit for designated initializers.

Yeah that is a footgun too. Enough that Rust defines argument evaluation order.

It is a much smaller footgun though and I don't recall ever being bitten by it. I have definitely been bitten by member initialisation order though multiple times. Generally because of questionable designs where one member is passed as a parameter of another member and it hasn't actually been initialised yet.

Really I think the answer is to initialise in the order that initialisation is written (this is what Rust does) rather than declaration order. But that would be a breaking change so I guess they opted for the conservative choice.

Yes, and there was a strong push to define the order although it ultimately failed.

On the other hand evaluation order of aggregate initializers is well defined (left to right) and there was little appetite to weaken it.

It might still happen in the future of course.

Fail to compile due to forward references in initializers.

The problem is, someone thought this was a good idea, but the act of supporting it ruled out a lot of more-useful future improvements.

Is `int B = A` even legal? Aren't field initializers like that supposed to be compile time constant?

It's allowed since C++11.

I wouldn't write that, and if someone did they'd get to keep all the pieces.

Weird that they claim to use arbitrary graphs, while in reality it's a weird subclass of DAGs with one-vertex loops kind of allowed, except they don't really make sense to be represented as loops.

What do you mean by sound? Mathematically sound means "there exists a model validating it", and of course it exists, but so what? If you mean you can bound the probability of error, then in your formulation you actually can't.

Bayesian inference is mathematically sound as it is based on a very generic postulates and allows to compare probabilities based in the current information and made a decision accordingly. With the proper approach the errors are automatically accounted for. I.e. if the errors are large, then one will see that probabilities are too close each other to make a sound decision. Still if one must made a decision, then one can just use the answer based on Bayesian reasoning.

The problem in practice is that accounting for the existing information is hard with guessing of priors etc. But that is the problem of applicability of Bayesian inference, not the problem with the principle itself.

I.e. Bayesian inference is a good answer to the philosophical problem of induction. It is sad that the article has not even touched on that subject.

That... that way to handle leap years can't possibly be right, can it? It doesn't account that you don't need to add the leap day of the current year if the day is before Feb 29

Err, my bad, I left out the prequel (still a one liner)

y -= m < 3; dow = as above, etc;

I was focused on an 'obscure' yet fundemental part of the C language pointer | array equivalence.

Addendum: https://c-faq.com/misc/zeller.html

>allow access and/or use of any open-source code to humans only;

That would be the most hilarious outcome possible. Oops, you can't store open source code on your computer, the access is only for humans!

Um, is SMS not tied to not losing a particular SIM card? I guess you can try to restore your number, do all operators provide this functionality?

My number is tied to my government issued ID. If I lose the SIM card I can get another one simply by showing my ID. If my ID gets stolen I can get another one by visiting the Police and so on.

The point is - I have some kind of an enforceable legal right to that number, whereas I currently have no such right to any particular account (and such rights can't be practically enforced for physical objects such as devices)

Yes, that’s what I want. There’s a much lower risk, for me, or government tyranny than me losing my yubikey.

Note though that it varies depending on the thing protected. For GitHub, I’m cool with the risk that the government gets a subpoena to seize my phone or SIM card and log into GitHub.

For some other services like messaging, I’d rather have stronger controls.

I'm pretty sure you're doing this already. We have courts for a reason, technocracy is a step backwards.

If the government ordered it you or anyone else would be given access to your account, no matter how many factors you have.