Counterproposal for extending static members and constructors

[Christophe Travert]

>> In any case, std.container already declares a make which encapsulates
>> constructing an object without caring whether it's a struct or class (since
>> some containers are one and some another), which I intend to move to
>> std.typecons and make work with all types. That seems a lot more useful to me
>> than trying to make a function act like a constructor when it's not - though I
>> guess that as long as you imported std.typecons, I would just be providing the
>> free function that your little constructor faking scheme needs.

The same can be said for UFCS. Your just faking member functions with a 
free function. I don't understand why constructors are so different.

A library might write generic code and use a constructor to perform 
something. I can't use that generic code if I don't own the struct or 
class and am able to write a constructor. You can argue that the library 
should have use make, instead of calling the constructor or using some 
cast. But they can't think of every usages, and may not know about make. 
Plus it may make the code uglier.

It's like standard UFCS. library writer should never call a member 
function, and always call a free function that is templated, specialised 
to use the member function if available, to provide workarround, or 
that can be further specialised if someone wants to extend the class. 
yuuuuk...