[Thorrez]

>When "out" and "in out" parameters are distinguished, there is no need for the existence of constructors as a separate concept. Any ordinary function with an "out" parameter can be used wherever C++ requires a dedicated constructor. Instead of constructors, it is enough to have an identifier convention for functions that should be called by the compiler when you want implicit initialization or implicit conversions.

Why do we need "out" vs "in out" parameters for this? Why can't a function that returns the object work just as well? And "an identifier convention for functions that should be called by the compiler when you want implicit initialization or implicit conversions" seems essentially the same as constructors to me.

>Moreover, there is no need to care about "copy" semantics and "move" semantics or about temporaries which are or which are not generated by the compiler. It is easy for the compiler to always choose the best implementation without programmer intervention, when it knows the correct parameter modes for the functions.

How would I implement something like std::vector with deep copy and move support of its contained objects without writing copy and move constructors (or operators)? There needs to be code saying "allocate a new block of memory and copy all the elements to that new block", and code saying "just copy the pointer, and set the other pointer to null". Are you saying the implementer would still write that code, just not in constructors/operators? How is that better?

[pyjarrett]

The big reason for `out` only is "I want to write here, but I don't care about the initial value." It's a more explicit version of the C++ `Foo& outFoo` output parameter paradigm.

> When "out" and "in out" parameters are distinguished, there is no need for the existence of constructors as a separate concept.

I don't agree with this. You can get I need to do things "post-init" with controlled types, or use a `return X : Thing do ... end return` block. Constructors help ensure invariants. You can make a type `is private` to prevent instantiation, only allowing creation via functions (sort of like Rust `new` associated functions), or initialization via an `out` param. It's OK but not perfect, but you can also tag on a `Type_Invariant` aspect if there are conditions which have to be met by a type. My big problem with Controlled types is that forces a type to be `tagged` (i.e. it has a vtable) which means it affects storage layout of values of that type, which isn't a problem in C++.

You can forbid copies by making something a `limited` type, but you'd have to write your own "Move" equivalent, and some of the containers have `Move` subprograms implemented to transfer contents. Limited types might elide the copy when returned from a function, but it's been a while since I looked at those rules.

[adrian_b]

In C++ or similar languages, where the function parameters behave semantically as either "in" or "in out" parameters, a function that returns an object must have already created somehow the object.

Therefore calling a function just adds a task of invoking a constructor also into the function, it cannot replace a constructor.

In C++, an object cannot be created by assigning a value to it, because the left hand parameter of the assignment operator is an "in out" parameter, like for any other function, so it is assumed that it already has a value of the type of that object.

Therefore an assignment operator must execute the equivalent of invoking a destructor for the target of the assignment, followed by the invocation of a copy constructor.

Attempting to assign a value to memory allocated but not initialized will attempt to invoke a destructor for an invalid object value.

The constructors are the only C++ functions that implicitly have a result which is an "out" parameter, not an "in out" parameter, like the other functions.

Because the memory where the result of the constructor will be placed is not initialized, no destructor must be invoked for it, so all will be OK.

All these rules about when to use constructors and when to use functions and the need to have duplicate almost identical in meaning functions for certain purposes, e.g. copy constructors and assignment operators, complicates a lot C++.

Any copy or deep copy operations would be implemented very simply, just by copying what needs to be copied.

There would be no need for "move" operations of any kind, which are just a trick to avoid the inefficient code generated by compilers when the semantics for some parameters is "in out" when what would have really been needed is "out".

Specifying that some functions are not normal functions, but constructors, or that some operations have "move semantics" is just an extremely complicated way to specify that some function parameters are "out", not "in out". Besides being hard to understand, these tricks only work in particular cases, instead of being able to specify the mode of any function parameter.

In a language with distinction between "in out" and "out", the mode for the result of assignment is naturally "out" and there is no need for the contortions of C++. In such a language a compiler knows when to invoke destructors and when not to invoke them and it knows when no extra temporaries are needed for computing a complex formula with objects.

[Thorrez]

>In C++, an object cannot be created by assigning a value to it, because the left hand parameter of the assignment operator is an "in out" parameter, like for any other function, so it is assumed that it already has a value of the type of that object.

While "the left hand parameter of the assignment operator is an "in out" parameter" is correct, I want to point out that

  Foo f = CreateFoo(1);

never calls the assignment operator. It either calls the move constructor, copy constructor (only if the move constructor doesn't exist) or does copy elision (meaning no copies or moves, more on that below).

>In C++ or similar languages, where the function parameters behave semantically as either "in" or "in out" parameters, a function that returns an object must have already created somehow the object.

If the object is being declared at the same time as being assigned to, and the function's return instantiates the object, e.g.

  Foo CreateFoo(int x) {
    return Foo(x);
  }
  
  Foo f = CreateFoo(1);

then as of C++17, this uses guaranteed copy elision. So there will be no copying or moving.

https://en.cppreference.com/w/cpp/language/copy_elision

Additionally, there are other situations where the compiler is allowed (but not required) to do copy elision, e.g.

  Foo CreateFoo(int x) {
    Foo result(x);
    return result;
  }
  Foo foo = CreateFoo(1);

Even if there isn't copy elision, usually move constructors (which is what will happen in the second example if the compiler decides to not do copy elision) are pretty cheap.

With Ada, if you want to call a function with an out parameter, doesn't the object for the out parameter need to be created before calling the function, and thus at least partially initialized? The article says "Non-scalar values like pointers are always initialised.'

>Therefore an assignment operator must execute the equivalent of invoking a destructor for the target of the assignment, followed by the invocation of a copy constructor.

If the assignment operator isn't used, this problem doesn't happen.

>Attempting to assign a value to memory allocated but not initialized will attempt to invoke a destructor for an invalid object value.

Can you give an example of where this would happen? This should never happen unless you're doing something strange. If you do things with standard high-level capabilities, you won't hit this problem. For example you can allocate memory without initializing it with vector.reserve() , then later initialize an object into that memory with vector.push_back() or vector.emplace_back() . If you want to go low-level (e.g. to implement vector yourself), you have to be careful to get things right, but it's possible to avoid the problem you mention by using placement new.

>All these rules about when to use constructors and when to use functions and the need to have duplicate almost identical in meaning functions for certain purposes, e.g. copy constructors and assignment operators, complicates a lot C++.

I agree it's complicated. But I don't think "in out" parameters would solve all the use cases. E.g. I don't think they can guarantee invariants like constructors and destructors can.

>There would be no need for "move" operations of any kind, which are just a trick to avoid the inefficient code generated by compilers when the semantics for some parameters is "in out" when what would have really been needed is "out".

move operations aren't just needed for output. They're also used for input. E.g.

  class Foo {
   public:
    void set_bar(std::string bar) { bar_ = std::move(bar); }
   private:
    std::string bar_;
  };

  Foo foo;
  std::string bar = CoputeBar();
  foo.set_bar(std::move(bar));

Here we can modify foo to contain a string, without copying the string. "in out" parameters wouldn't replace move semantics here in terms of avoiding copies.