Mynx Constructor Design Semantic Considerations

For Mynx I'm working out the semantics regarding class elements, and one has me going in two directions -- the constructor.

Mynx has 3-basic parameter passing modes (all by reference):

1. in - non-null passed, object reference immutable
2. out - nullable possible to pass, object reference can change
3. var - non-null passed, object reference can change
4. series - non-null, passed, object reference immutable

Note that all objects are not primitives, even the basic types are objects.

For a constructor, my thinking is the semantic constraint that only in parameters are passed to create and initialize an object instance.

Example toy class in Mynx, toy.mynx  :


    class Toy is
 
       public construct(in String str, in Char chr) is
          !! do something here !!
       end construct;

       public construct(out Bool bl) is
           bl = Bool.True;
       end construct;
 
    end class;


The idea is to avoid any parameter changes within the constructor, its sole purpose is to create and initialize an object instance -- changing or creating a new instance within and altering a passed argument is semantically incorrect. But...is it?
Another point is a constructor is to initialize a new instance, passing an object out would be returning a value, something a constructor does not do.

Consider the Mynx code fragment:

    Bool flag to null;
    Toy ty to null; //declare a toy instance but null reference

    ty as Toy("hello","c"); //pass in literals -- semantically ok

    ty is null;

    ty as Toy(flag); //pass boolean -- semantically ok??


The first constructor invocation passed literals, which are immutable, and the parameter mode are both in-parameters, so semantically valid. The second construtor invocation a Bool object for a boolean flag is passed into the constructor, so a boolean value is returned -- semantically valid or invalid??

This semantic concern is reminiscent of Pascal's ability to pass procedures or functions as parameters which created a semantic loop-hole...although I'm leaning towards semantically strict, but want to give a developer some "wiggle room".

One other possibility is to use a factory method that explicitly returns values as parameters, and/or an "initialize" method to allow returning parameters that are created or changed -- but the constructor cannot implicitly do it.

Note: I've decided to go with 'in' style const immutable parameters that cannot be changed, a constructor should take parameters and create (or duh, construct...) a new class instance. Looking at C++, the copy constructor takes an immutable instance of the same class and creates a copy of it, but the passed parameter is not changed. So C++ copy constructor semantics are in line with Mynx constructor.