auto sum = [](auto a, auto b): a+b;

yes, mozilla's TOS update is a bad thing, but switching to chrome (or chromium-based) for it is really cutting your nose to spite your face.

if you added 200ms latency to your mouse inputs, you’d throw your computer out the of the window pretty quickly.

i’d consider myself a day-to-day c++ engineer. well, because i am. i like lots of things from rust. there’s a few things i don’t. c++ has a lot to learn from rust, if it is to continue to exist.

but really.. isn’t this the point of the language? you need to understand the borrow checker because.. that’s why it’s here?

maybe i’m missing something.

fully unscrew the cap then just either continue twisting the cap over the the edge - honestly effortless - or just.. pull it off? the cap still functions as a cap, afterward.

apologies, but i don’t understand the furore over this change.

really, i’m not trying to be mean here. you assert life must be finite, and all i’m asking is how finite it should be.

if modern a modern 60Hz LCD/OLED display couldn't get beneath 16.6ms latency, then what exactly is tearing?

otherwise, yes, modern APIs go out of their way to avoid the possibility of this (the dreaded "tearing" artifacts you see from the frame buffer being changed during the transmission of the video signal to the monitor). i don't believe older techniques like you've mentioned are at all possible today, and only really made sense to talk about when analogue displays were the norm.

thats actually not true. you seem to be implying that the best a 60hz display can manage is 16.6ms of latency. indeed that is the worst case value, but you should consider that early graphics technologies involved changing display modes mid scan.

it’s actually not ridiculous to suggest that old platforms had sub-millisecond latency; they did. if the scanline was on, or just before, the line where you would interact (i.e., the prompt line), the text you enter would appear immediately.

of course, “vsync”, tear free, and such like approaches “fixed” this - necessarily by adding at least a frame’s worth of latency - but also adding perceptual latency.

it’s an oft-overlooked aspect of refresh rates. a 60hz CRT, without vsync, still has the lower bound of latency lower than a 120hz display. perhaps even 240hz.

i’ve used two 240hz displays for years now. i’ll never go slower than that.

a system user/admin has an intuition about files. saying that ‘journalctl -f -u’ (fu, indeed :) and whatever else is inherently undiscoverable, and is a.. basically orthogonal mechanism for handling what should be a simple task. i.e., viewing some logs. it’s far easier to compose and extend from files (what if i only care about the mtime of the log, for instance), than this.

look, i think systemd isn’t.. terrible. i also think it’s suffered a bit of complexity fetishisation, and it seems as though that this resulting complexity may have become invisible to you.

run0 doesn’t seem like a bad idea. but i am wincing a bit at the thought of unrestricted javascript determining access control.

you, or i, don’t get to decide what’s fair to treat, or who’s deserving of treatment.

i dunno, i feel like the wording of this error message could be improved :)

and deep ground is not ridiculous. we’re expecting the storage to be in the “mostly write only” regime, after all.

of course, across the TU boundary things get difficult, but i don’t think it’s fair to dismiss LTO entirely (although.. i agree with the thesis that it’s not particularly.. good)

similarly, de-virtualisation is an optimisation technique compilers will aggressively use to improve performance, although you’re right that it can’t look through another source file, so it is not without limitations here.

but we’re not being general, we’re being specific; the safety issues that are being discussed are well within the remit of the c++ type system here, and i don’t think we’re doing any favours to anyone by letting this rvalue be accessed in this way. it is certainly not idiomatic to provide library code that can so violently implode with seemingly regular use. i find it difficult to believe that lifetime issues like this are undiagnosable.

perhaps for values like this you’re fine. i think my point still stands about the reader of a built-in list/sequence type, surely?

and, not to sound facetious, that’s exactly what optimisers do :)

the c++ type system is more than capable about reasoning about lifetimes, the issue is that, with c++, it’s an optional part of the language. also, the lack of non-destructive moves. but to require both of those things in the language would require, essentially, the borrow checker in rust.

regardless of that outcome, i think i’d prefer to require a value preserving the lifetime of the reader/view. in the cases that it may not be necessary, i'd prefer to lean on the optimiser to take care of it..!

is it not possible to delete the rvalue reference overload of ‘getList’?

as far as i can tell, the error producing code wouldn’t have produced a diagnostic, but failed to build in the first instance, like the rust case?

i don’t doubt this will also get shutdown in the near term, but i’m 70% confident in a surprising acquisition & continued support from apple in the longer term.

it will be hard for apple to continue to claim they are pro-user when they appear to be this hostile toward android users.