lambalicious

joined 2 years ago
[–] [email protected] 3 points 1 hour ago

Not a bad idea. I'll try to crosspost that news a few times later during the weekend to help build the bad behaviour portfolio.

[–] [email protected] 1 points 1 hour ago

.at_unchecked()

What kind of barbarism is that?

Doing that kind of split would kill genericity (more than it already is). If I'm using [] is because what I want is, more or less, to just access the value; not to maybe randomly and without any kind of source-level control or projected time/space boundaries go to the blockchain to check if the Rust devs are in the mood today to have blessed the given statement with the arguments given.

Frick. At least give me something like [checked(5)] or [unchecked(5)] for a more natural syntax. The more considering it has been possible to add compile-time checked access with something like [integral_constant<size_t,5>{}] since at least C++03! It just needs someone to propose a standardized notation shortcut. Or if there was some way to inquire or static_assert that the checks on the natural syntax are actually elided if I'm doing them myself elsewhere. But at it stands, uglifying the syntax is the worst of all worlds.

[–] [email protected] 4 points 23 hours ago

Well, you'll need dopamine and serotonin for all the new product spam mails you can get!

[–] [email protected] 1 points 1 day ago (2 children)

I think it’s pretty much guaranteed that they’re not going to take the sensible route of making it opt-out,

Because that's not the sensible route in the future, whether we like it or not. Hardened STL is being announced in the papers as "we are going to start with these silly one-line fixes that in theory should perturb no one, but as we iterate over this we're gonna start breaking things", which is not what you want to hear from the default.

One good example: placing enforced bounds check into the operator[] of std::array<> of all places. People keep telling me that I should be using std::array instead of normal C arrays, but then punish me for using std::array? That ends up making people revert to the True Old Ways That Work (aka: C arrays).

[–] [email protected] 1 points 1 day ago

How cute that you believe that.

[–] [email protected] 4 points 1 day ago

imagine someone comes over to your place and starts protesting and saying how bad you are

What, you want them to lie to you to your face?

[–] [email protected] 2 points 1 day ago

¿Puede compartir el dato? Como para ver los specs igual, necesito notebook nuevo, y harto mejor si es un AMD...

[–] [email protected] 3 points 1 day ago

This should like… just not be a rule though

Eh it's issues with l.w mods being overall cowards.

[–] [email protected] 3 points 1 day ago (1 children)

but isn’t one of the job of the police supposed to actually check people’s ID?

Define "people's", because not doing so is how we get into a police state and that was some Germany shit. Everyone? A subset at random? A subset at convenience? A subset based on how brown they look?

[–] [email protected] 1 points 1 day ago (2 children)

Think of the lemmy.world mods!!!!

 

publicado de forma cruzada desde: https://gregtech.eu/post/6514020

[email protected] gang, rise up

 

(Only half joking with the poll options, too.)

 

Aquí en la mejor instancia de feddit celebramos el largo de Chile. Y en otras instancias, parece que también.

 

RFC 3339, the "alternative" to ISO 8061, was extended to RFC 9957, which also allows adding interpretative tags.

Sounds like unnecessary complexification to me. What is wrong if anything with "2024-04-26"?

 

publicado de forma cruzada desde: https://lemmy.world/post/9470764

  • ISO 8601 is paywalled
  • RFC allows a space instead of a T (e.g. 2020-12-09 16:09:...) which is nicer to read.
 

I've seen the Wikipedia article on year 9 doesn't mention anything of relevance happening during November. Closest thing seems to be September. Since people around have spent a few years making lots of ruckus about how the date with "9, 11" has some sort of importance as a date, I was wondering if I'm missing something here.

 

Basically title. 2019 edition of the Standard denotes the "T" prefix to time as mandatory (except in "unambiguous contexts"):

01:29:59 is now actually T01:29:59, with the former form now designated as an alternative

But date does not have a "D" prefix, not even in "ambiguous contexts".

1973-09-11 never needs to be something like eg.: D1973-09-11

Anyone know the reasoning behind this change and what is the intended use? The only time-only format with separators that I can think would be undecidable in ambiguous contexts would be hh:mm which I guess could be mistaken for bible verses?

 

I mean, it's the obvious choice. So why not? Maybe we can do with the zoom on the cat if there is a better version.

view more: next ›