search

hsutter / cppfront

A personal experimental C++ Syntax 2 -> Syntax 1 compiler
Other
5.54k stars 246 forks source link

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

Open JohelEGP opened 1 year ago

JohelEGP commented 1 year ago

Title: Consolidated feedback on enabling more argument qualifiers.

Introduction:

Currently valid:

Currently invalid:

Other contexts where those keywords can be valid: https://github.com/hsutter/cppfront/issues/456#issuecomment-1547913413.

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). -- https://github.com/hsutter/cppfront/pull/198#issue-1520183742 (extract)

in x would be an useful shorthand for std::as_const(x). Although in does more when applied to a parameter. -- https://github.com/hsutter/cppfront/pull/198#issuecomment-1529282080 (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

-- https://github.com/hsutter/cppfront/issues/425#issuecomment-1546750375 (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. -- https://github.com/hsutter/cppfront/issues/425#issuecomment-1546760953 (extract)

But according to this comment #425 (comment) , it works on pointers https://cpp2.godbolt.org/z/Tx8e9KfKc f<* const int>(); -- https://github.com/hsutter/cppfront/issues/456#issue-1708759034 (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". -- https://github.com/hsutter/cppfront/pull/198#issue-1520183742 (extract)

For copy we probably want to avoid doing an extra second copy unconditionally when we might be calling a copy-declared parameter. -- https://github.com/hsutter/cppfront/pull/198#issuecomment-1374969617 (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. -- https://github.com/hsutter/cppfront/pull/198#issuecomment-1483685807 (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. -- https://github.com/hsutter/cppfront/pull/369#issuecomment-1556257664 (extract)

An extra copy would happen if the cv unqualified type of the argument and of the (type referenced by the) parameter are different. -- https://github.com/hsutter/cppfront/pull/198#issuecomment-1529282080 (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 https://github.com/hsutter/cppfront/issues/305#issuecomment-1586580100.

Old quotes: > > `inout` in-particular seems like important information I'd like to see at call sites. > > -- (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. > -- (extract) **[M](#last-use)ove 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. > > -- (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. > -- (extract) Then follows a very long discussion starting with . 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: - #288 - #396 Also asked at: -

See also:

JohelEGP commented 1 year ago

f(inout x)

The need for this is resolved, see https://github.com/hsutter/cppfront/issues/305#issuecomment-1586580100.