Statement scope parameter default: in or copy?

[hsutter]

[edited to add Case 4]

This poll arises from #1000, and concerns statement scope parameters, such as a counter for a loop or :

value: std::string = "xyzzy";  // a local variable

// Case 1: a read-only statement scope `val` view of a local variable
(/*...*/ val := value) {
    std::cout << val;
}

// Case 2: a read-write statement scope `val` view of a local variable
(/*...*/ val := value) {
    val += "plugh"; // side effect on `value`
}

// Case 3: a statement scope `counter` initialized with a literal/const value
(/*...*/ counter: int = 1)
for  words
next counter++ 
do   (word) {
    std::cout << "(counter)$: (word)$\n";
}

// Case 4: a statement scope variable
(/*...*/ val := value) {
    std::cout << val;
}
// Here a `copy` default is consistent with a local variable:
{
  val := value;
  std::cout << val;
}

The question is, should the default /*...*/ parameter passing qualifier be in or copy?

If in (the current status quo):

• a statement parameter has the same default as for other parameters
• a statement parameter is read-only by default, and no copy/move is performed for non-cheap-to-copy types
• case 1 doesn't have to write anything special (in val would be the default)
• case 2 has to write inout val
• case 3 has to write copy counter
• case 4 has to write copy val and is not consistent with a local variable val := value; which means copy

If copy (as it has been in the past before this commit):

• a statement parameter has a different default vs. other parameters
• a statement parameter is read-write by default, and a copy/move is always performed
• case 1 has to write in val
• case 2 has to write inout val
• case 3 doesn't have to write anything special (copy counter would be the default)
• case 4 doesn't have to write anything special (copy val would be the default) and is consistent with a local variable val := value which means copy

Note: I'm deliberately not offering options like "make the default be copy if the initializer is literal/const, and in if the initializer is mutable" or similar context-dependent meanings.

[gregmarr]

Having it be copy would make these two equivalent, which I believe was the intent.

(val := value) {
    std::cout << val;
}

{
  val := value;
  std::cout << val;
}

[hsutter]

Thanks! Good example, I'll add that to the poll description.

[hsutter]

Added as Case 4.

[zaucy]

I voted for in for consistency sake, but I would like to mention that the given example in #1000 of creating an index can be solved with std::views::enumerate.

words: std::vector<std::string> = ("Adam", "Betty");

// for enumerate(words) do ([i, word]) {            // some destructuring syntax maybe?
// for words | std::views::enumerate do (entry) {   // pipe operator instead
for std::views::enumerate(words) do (entry) {
    i := std::get<0>(entry);
    word := std::get<1>(entry);

    std::cout << i << ": " << word << "\n";
}

Not to say that there aren't other cases where copy being the default is more convenient. I only wanted to point out alternatives.

[bluetarpmedia]

Not to say that there aren't other cases where copy being the default is more convenient. I only wanted to point out alternatives.

Yeah, I like the destructuring syntax you suggested.

I've been playing around with converting example code from cppreference into Cpp2, and here's another case I came across where the copy requirement doesn't seem intuitive to me:

Cpp2 translation of std::condition_variable example from cppreference

#include <thread>  // Not sure yet why this is needed in my Godbolt setup

m: std::mutex = ();
cv: std::condition_variable = ();
data: std::string = ();
ready: bool = false;
processed : bool = false;

worker: () = {
    (copy lk: std::unique_lock = (m))
    {
        cv.wait(lk, :() -> bool = ready);

        std::cout << "Worker is processing data\n";
        data += " after processing";

        processed = true;
        std::cout << "Worker thread signals data processing completed\n";

        _ = lk.mutex();  // Workaround for UFCS and last-use std::move bug
    }
    cv.notify_one();
}

main: () -> int = {

    worker_thd: std::thread = (worker);

    data = "Example data";

    (copy _: std::lock_guard = (m))
    {
        ready = true;
        std::cout << "main() signals data ready for processing\n";
    }
    cv.notify_one();

    (copy lk: std::unique_lock = (m))
    {
        cv.wait(lk, :() -> bool = processed);

        _ = lk.mutex();  // Workaround for UFCS and last-use std::move bug
    }

    std::cout << "Back in main(), data = " << data << '\n';

    worker_thd.join();

    _ = m.native_handle();   // Workaround for UFCS and last-use std::move bug
    _ = cv.native_handle();  // Workaround for UFCS and last-use std::move bug

    return 0;
}

Godbolt

The relevant parts look like this:

// m: std::mutex = ();
// cv: std::condition_variable = ();

(copy lk: std::unique_lock = (m))
{
    cv.wait(lk, :() -> bool = some_condition);
}

[MaxSagebaum]

I think in case 3 a counter += 1; is missing.

Also voting for the consistency of in.

[hsutter]

Added, thanks!

[hsutter]

Thanks, everyone! I'll close this as "status quo" for now, and we can always reopen it again in the future if we get new information.