| Time |
Nick |
Message |
| 00:11 |
MTDiscord |
<wsor4035> i kicked it |
| 04:00 |
|
MTDiscord joined #luanti-dev |
| 05:15 |
|
mrcheese joined #luanti-dev |
| 06:12 |
|
YuGiOhJCJ joined #luanti-dev |
| 06:24 |
|
YuGiOhJCJ joined #luanti-dev |
| 07:10 |
sfan5 |
@luatic sounds sane |
| 07:18 |
|
YuGiOhJCJ joined #luanti-dev |
| 08:55 |
MTDiscord |
<herowl> I don't like the argumentation and do like the uniform initialization. |
| 08:57 |
MTDiscord |
<herowl> Are we absolutely sure the compiler will be optimizing out the copies in all cases? |
| 09:22 |
sfan5 |
if you think it's slower that will be easy to prove using godbolt.org |
| 15:30 |
MTDiscord |
<josiah_wi> Herowl, are copy semantics related to initialization style at all? |
| 15:37 |
MTDiscord |
<josiah_wi> My understanding of uniform initialization is that it is meant to provide a consistent initialization syntax to replace a mix of different initialization styles. I think the Abseil tip makes a case for limiting use of uniform initialization in existing codebases, although their argument also leads to the conclusion that features such as std::for_each should be avoided in legacy codebases because they could be unfamiliar to some devs |
| 15:37 |
MTDiscord |
(this is a real issue BTW and not intended entirely as satire). |
| 15:39 |
MTDiscord |
<josiah_wi> I think their argument is fairly weak, because not being familiar with a strange syntax is not generally a good excuse to forbid it. I think it boils down to an aesthetic preference war, and the smartest thing to do is do whatever the person in charge says to avoid drama. |
| 15:44 |
MTDiscord |
<luatic> That is entirely possible, but then we should stipulate one thing or the other so it's one and done. |
| 15:45 |
MTDiscord |
<josiah_wi> Also, the fact that they call it direct initialization bothers me. Especially the sentence "for the language lawyers: prefer copy-initialization over direct-initialization when available, and use parenthesis over curly braces when resorting to direct-initialization." Direct initialization refers explicitly to the form with parentheses. This can easily be confirmed on cppreference and I don't think you even have to be a "language |
| 15:45 |
MTDiscord |
lawyer" to know this. The fact that the author of this Abseil article doesn't know this, and is spouting this incorrect terminology under the claim of using technically precise terminology, makes me think the author doesn't know his stuff. |
| 15:46 |
MTDiscord |
<josiah_wi> It's harder for me to give ear to a persuasive argument that sounds like it was written by someone who knows way less than I do. Usually it's people who know more than I do who end up changing my opinions. |
| 15:48 |
MTDiscord |
<josiah_wi> He was spot on with pretty much everything else including his knowledge of the design rationale, but that one thing really got on my nerves. |
| 15:48 |
MTDiscord |
<luatic> Is that so? https://en.cppreference.com/cpp/language/direct_initialization does list T x{...} syntax as direct initialization? |
| 15:49 |
MTDiscord |
<josiah_wi> No kidding, I was wrong. I have been misinformed. |
| 15:49 |
sfan5 |
I think https://en.cppreference.com/cpp/language/initialization is clearer |
| 15:51 |
sfan5 |
the only wrong part I see is with "and use parentheses over curly braces when resorting to direct-initialization.": the parentheses stuff is called "List-initialization", which is different from "Direct-initialization" |
| 15:52 |
sfan5 |
s/parentheses/curly braces/ |
| 15:52 |
MTDiscord |
<josiah_wi> Well, it's called direct initialization when used with a non-class type apparently, so he's sort-of-right even in that regard. |
| 15:54 |
MTDiscord |
<josiah_wi> Thank you, luatic. I could have misled so many people down the road if you hadn't corrected me. |
| 15:56 |
MTDiscord |
<luatic> np |
| 15:56 |
MTDiscord |
<luatic> frankly i just want to get some kind of rule written down so we can stop talking about this :p |
| 15:57 |
sfan5 |
link the article and call it a day, imo |
| 16:49 |
Krock |
I see lots of activity for the other physics code refactor - might anyone have time to look at #17127 ? It is targeted to fix strange ceiling collisions but needs testing, which isn't going to happen by keeping the PR idle. |
| 16:49 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/17127 -- Collision: Update position based on collisionbox faces by SmallJoker |
| 22:32 |
|
panwolfram joined #luanti-dev |
| 23:03 |
|
dv^_^ joined #luanti-dev |
| 23:24 |
|
YuGiOhJCJ joined #luanti-dev |
| 23:48 |
|
swags joined #luanti-dev |
