That code has undefined behavior due to data race, but your point could be
more easily made with https://godbolt.org/z/qv6xqjo11 , I think.

On Sat, Jan 7, 2023 at 4:42 PM Phil Bouchard via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> On 1/7/23 01:22, Jason McKesson wrote:
> > Your insistence on using rich text (aka: shoving HTML into peoples'
> > inboxes) rather than plain text is making this conversation difficult
> > to engage in, so I'm just going to cut out my portions rather than
> > take the time to fix the broken quotes that your posts always create.
>
> Sorry about that.
>
> > On Sat, Jan 7, 2023 at 12:43 AM Phil Bouchard <boost_at_[hidden]> wrote:
> >>
> >>
> >> Well I don't know, even Visual Studio used to lessen that restriction:
> >>
> >>
> https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4350?view=msvc-170
> >>
> >> So it's not essential.
> >
> > What does that mean, "essential"? In the literal sense, *nothing* in
> > C++ is "essential". Everything is conceptually malleable.
> >
> > But the fact that one compiler was broken for a while is not evidence
> > that the feature was a bad idea.
> >
> >> In any case my own personal goal is to simplify the syntax as much as
> possible to make the code readable and maintainable. There are cases you'd
> want to disregard the output variable as well, and this is my no mean the
> called function's concern. Ex:
> >>
> >> Input code:
> >>
> >> void foo(ostream & log);
> >>
> >> ...
> >>
> >> foo(ostream());
> >>
> >>
> >> Converted code:
> >>
> >> void foo(ostream && log);
> >>
> >> ...
> >>
> >> foo(move(ostream()));
> >>
> >>
> >> Again my own personal goal is to keep the code as simple and clean as
> possible to ease code maintenance over long term. I know from experience
> this is not a bad thing.
> >
> > You can say "simple and clean" all you want, but that doesn't make the
> > "converted code" simple *or* clean. It is instead both overly wordy
> > and confusing.
> >
> > Your code creates a prvalue (I'll ignore that `std::ostream` is a
> > pure-virtual class, so you can't actually do that) and then
> > `std::move`s from it. That... does nothing useful at all. The behavior
> > is exactly identical to The simpler and cleaner form would be
> > `foo(std::ostream())`.
> >
> > Less text is both simpler and cleaner. Especially if that extra text
> > accomplishes nothing.
>
> Well the input code is the code the Fornux C++ Superset source-to-source
> compiler would be processing. The output code would be the generated
> code. All parameters would be passed using the move() semantics and if a
> function decides it doesn't want to change its value then it should be
> qualified as "const" quite simply.
>
>
> > As for the "conversion" as a concept... no. If a function, by its
> > nature, outputs data to a reference parameter, and a user wants to
> > just throw away its output, they can do that. But they can't do it in
> > one line. This is a *good thing*, because it signals to everyone
> > reading that you're doing something *unusual*.
> >
> > Unusual code should not be clean-looking. Bugs *love* unusual code. As
> > such, it deserves more scrutiny (like wondering why it is you're
> > calling a function and ignoring its output). And seeing two lines to
> > call a function calls attention to the fact that something weird is
> > going on.
> >
> > This is a good thing.
>
> I strongly disagree here but I guess we don't have the same requirements
> and goals anymore.
>
> Fornux C++ Superset is a higher level layer on top of C++ that
> implicitly fixes all memory bugs and is less restrictive on the syntax,
> as previously stated.
>
> In fact a good example to follow is the Lisp language syntax:
> https://www2.cs.sfu.ca/CourseCentral/310/pwfong/Lisp/1/tutorial1.html
>
> Despite the garbage collector I always disliked in Lisp, the developer
> clearly worries about the high level algorithm, not low level
> technicalities. That speeds up the development time greatly.
>
> Also when you write a function you really don't care whether the user
> will use an r-value or an l-value. All you know is whether you'll really
> modify the value, and if you require a copy of it or not.
>
> When I think about it, "const &" is really problematic. Consider the
> file attached, the executable will consequently output:
>
> 1
> 2
> 3
> 4
> 5
> 6
>
> Even if the thread "process2" expects a constant value that shouldn't
> change. So "const &" declarators are actually more dangerous than the
> redundant "move()" wrapper function calls I'm bringing.
>
> My point here is C++ has much bigger issues to solve right now and this
> is what Fornux C++ Superset is already doing / planning to do.
>
>
> >> std::move() states that an object *may* be moved from:
> >>
> >> https://en.cppreference.com/w/cpp/utility/move
> >>
> >> So it essentially doesn't mean anything "legally" speaking.
> >
> > You can lie in any language; that doesn't make lying a good idea. You
> > can write an iterator for a linked list container that claims to be a
> > random access iterator despite its sized-increment functions being
> > unable to execute in constant time. Nobody can stop you from lying,
> > but lies don't count as good code.
> >
> > If someone sees `std::move` in your code, it is reasonable for them to
> > assume that you are... moving the object. That's literally why it's
> > called *std::move*. In fact, if you look at the original proposals for
> > rvalue references, in the early ones, rvalue references could bind to
> > lvalues. The impetus for adding `std::move` and forcing people to use
> > it for lvalues was *specifically* to make it so that people know that
> > if they see `std::move` in code, then they know that a move is going
> > on (and if they don't see one, then no lvalue is being moved from).
> >
> > This understanding of the meaning of this syntax is so common that
> > it's part of the Core C++ Guidelines:
> >
> > *
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f15-prefer-simple-and-conventional-ways-of-passing-information
> >
> > *
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f17-for-in-out-parameters-pass-by-reference-to-non-const
> >
> > *
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-consume
> >
> > Indeed, the first line of the first link is particularly apt for this
> > scenario: "Using 'unusual and clever' techniques causes surprises,
> > slows understanding by other programmers, and encourages bugs."
> >
> > You can use the language however you see fit. But if you do something
> > that is the opposite of how everyone else is doing it, you don't get
> > to claim that your code is "simple and clean".
> >
> > Well, you can claim that. But don't expect people to take you seriously.
>
> Again, I see we don't have the same goals and requirements so we're
> comparing oranges with apples. Fornux C++ Superset is designed for
> higher level programming, taking the best out of every other programming
> languages.
>
> Thanks for your references.
>
>
> Regards,
>
> --
> Logo <https://www.fornux.com/>
> *Phil Bouchard* facebook icon
> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
> CTO
> T: (819) 328-4743
> E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com>
> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada
>
> Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les
> documents l'accompagnant, sont destinés uniquement aux personnes
> identifiées et peuvent contenir des informations privilégiées,
> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce
> message par erreur, veuillez le détruire.
> This communication (and/or the attachments) is intended for named
> recipients only and may contain privileged or confidential information
> which is not to be disclosed. If you received this communication by
> mistake please destroy all copies.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>