Date: Sat, 7 Jan 2023 14:42:44 -0500
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,
> 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.
Received on 2023-01-07 19:42:45