Skip to content

[BUG] Consolidated feedback on enabling more argument qualifiers #466

Closed as not planned
@JohelEGP

Description

@JohelEGP

Title: Consolidated feedback on enabling more argument qualifiers.

Introduction:

Currently valid:

  • f(move x)
  • f(forward x)
  • f(out x)

Currently invalid:

Other contexts where those keywords can be valid: #456 (comment).

in:

Personally, as a user, if I know I can use some of them, I'd expect the ability to use all of them (with maybe the exception of in).
-- #198 (comment) (extract)

in x would be an useful shorthand for std::as_const(x).
Although in does more when applied to a parameter.
-- #198 (comment) (extract)

Possibly related: I'm using library (flecs) with API like

ecs.system<Position, const Velocity>()

And haven't found way to specify that const in template call to system()

  foo<const int>(); //error
  foo<in int>(); //error

-- #425 (comment) (extract)

I don't think that can work.
In a subexpression, a parameter direction operates on an expression, not a type.
cppfront doesn't have enough semantic information for f<in int>() to work.
-- #425 (comment) (extract)

But according to this comment #425 (comment) , it works on pointers
https://cpp2.godbolt.org/z/Tx8e9KfKc
f<* const int>();
-- #456 (comment) (extract)

copy:

copy at call sites could be useful too. You could be saying "hey, no matter what the function signature says, take a copy of this value. I don't want you to change it and/or I don't want to accidentally change it out from under you".
-- #198 (comment) (extract)

For copy we probably want to avoid doing an extra second copy unconditionally when we might be calling a copy-declared parameter.
-- #198 (comment) (extract)

As I understand it, the function parameter is initialized from the argument, which in this case would be a prvalue. Guaranteed copy elision should mean no extra copy. Clang and GCC seem to agree: https://compiler-explorer.com/z/Gr63qhY44.
-- #198 (comment) (extract)

You can initialize a parameter from a prvalue of a non-copyable non-movable type: https://compiler-explorer.com/z/Y1x5nMT16.
So there should be no extra copy.
-- #369 (comment) (extract)

An extra copy would happen if the cv unqualified type of the argument and of the (type referenced by the) parameter are different.
-- #198 (comment) (extract)

I also think copy should subsume C++23's auto{x}.
#408's PR allows copy x outside an argument list, permitting this generalization.

inout:

The need for this is resolved, see #305 (comment).

Old quotes:

inout in-particular seems like important information I'd like to see at call sites.
-- #198 (comment) (extract)

For inout (or mut) we probably want to know that we're calling an inout- or possibly move-declared parameter. But we don't know those things unless we implement more name lookup and possibly overload resolution (neither of which cppfront has to do now) which is a big job I want to defer until later.
-- #198 (comment) (extract)

Move from last use:

Starting with #231 (68 comments).

When cppfront moves x on its last use it breaks the requirements of the f2 function that requires an lvalue reference but gets an rvalue reference.
-- #231 (comment) (extract)

One way to suppress this could be to require a mutating argument to be qualified with inout, which I've thought of and @jbatez suggested in #198.
-- #231 (comment) (extract)

Then follows a very long discussion starting with #231 (comment).
It proposes to look into a way to opt-out of a function call's results,
consistent across the return value and inout/out arguments.

Duplicates:

Also asked at:

See also:

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions