Counterproposal for extending static members and constructors

[Jonathan M Davis]

On Friday, July 13, 2012 08:10:46 Christophe Travert wrote:
> >> 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...

The primary advantage of UFCS is in aiding generic code. It's what allows us 
to use arrays as ranges without adding front, popFront, etc. to the language 
itself.

Constructors, on the other hand, are the complete opposite of generic, and 
they generally _can't_ be generic. Not only does whether you use new or not 
with them differ depending no the type, but the arguments required differ 
considerably from type to type even if their APIs are identical. It's the API 
of already constructed objects which makes things generic, not construction.

make allows you to not care whether you're constructing a struct or a class 
(it uses new for a class and doesn't for structs), so it helps abstract that 
away, but it doesn't abstract away the arguments. What they need to be depends 
entirely on what's being constructed. Generic construction rarely makes sense.

And I'd argue that if we don't already have too much magic with UFCS as it 
stands, then we're darn close. You can't look at a member function call any 
more and even know if it's a member function! Now you want to make it so that 
you can't even know if a constructor is a proper constructor? Yuck.

- Jonathan M Davis