https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md
Uncategorized
8
Posts
4
Posters
1
Views
-
Unsurprisingly char8_t is banned
-
Unsurprisingly char8_t is banned
Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.
-
Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.
This makes so much sense and applies to pretty much all codebases I've seen.
-
Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.
@vitaut But the document also banned UDL, so you can't use "text"sv
-
This makes so much sense and applies to pretty much all codebases I've seen.
@vitaut even me who is pro “existing code must rebuild unmodified , no changes means no changes” and “fopen and main must agree which prevents making fopen take utf-8 by default” agrees with this.
-
@vitaut they got them fancy 🧀 swiss maps
-
@vitaut But the document also banned UDL, so you can't use "text"sv
@lichray that’s fine
-
undefined oblomov@sociale.network shared this topic on
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@evan No matter whether Bob replied as "followers only" or " everyone", Bob's followers should be able to see his reply. They shouldn't be able to scroll up and see Alice's orignal post unless they also follow Alice. But Alice's choice for her own post should not override Bob's choice for his.
-
Yes, that seems like a good analogy.
-
@evan You've never asked anybody who has a private or follows only account about this have you? There doesn't need to be a massive data, but takes one response and it becomes really difficult to decide to follow the sloppy pattern and keep pushing it forward.
It is an easy path forward to do the right thing.
I’m here to help you.
-
So that etiquette would demand that Bob limit the visibility of his reply to just Alice, and let her decide how far it should reach beyond that. There's a certain grace there, but does the etiquette of telephony translate to microblogging?
-
I’ve always modeled this challenge as a set theory maths problem and the answer is the original set regardless of who is replying, as the original poster set the limiting constraint conditions + selected the members of the group with access to the conversation thread.
Plus there are “n” Bob’s, where “n” is the number of Alice’s followers.
-
@skobkin I always read it as "visible for the OPs followers" like it's implied that "followers only" is applied to the root of the thread.
But after our previous discussion this can definitely be clarified 🤔
@evan
-
@saerdnaer I didn’t know, sorry 🤦♀️
