Consistency, Templates, Constructors, and D3

[David Piepgrass]

>>> And a postblits would end up being...? The extra 'this' makes 
>>> it look like an obvious typo or a minor headache.
>>>
>>> this this(this){} //postblitz?

This is not an appropriate syntax, not just because it looks 
silly, but because a postblit constructor is not really a 
constructor, it's is a postprocessing function that is called 
after an already-constructed value is copied. So I don't think 
there's any fundamental need for postblit constructors to look 
like normal constructors.

>> I'm sure this case has an easy solution. How about:
>>
>>    struct Foo {
>>        this new() { ... } // constructor
>>        this() { ... } // postblit
>>    }
>
>  But now you're breaking consistency by not including a return 
> type. maybe 'this this()' but that looks like a mistake or typo.

I don't see how "this this()" is any worse than "this(this)"; IMO 
neither name really expresses the idea "function that is called 
on a struct after its value is copied". But a postblit 
constructor doesn't work like normal constructors, so keeping the 
"this(this)" syntax makes sense to me even though it is not 
consistent with normal constructors. "this()" has the virtual of 
simplicity, but it's even less googlable than "this(this)".

>> And for overload distinction (new vs load), which is an issue 
>> beyond Memory Pools and effects and even larger codebase. 
>> There needs to be a consistent way to distinguish (by name) a 
>> constructor that loads from a file, and one that creates the 
>> object "manually".
>
>  Isn't that more an API issue?

Sorry, I don't follow.

>>> If we take your approach and suggestion, which one should the 
>>> compile assume?
>>>
>>> Something globalSomething;
>>>
>>> class Something {
>>>  this defaultConstructor();
>>>  this duplicate(); //or clone
>>>  this copyGlobalSomething();
>>>  this constructorWithDefault(int x = 100);
>>> }
>>>
>>> By signature alone... Which one? They are all legal, they are 
>>> uniquely named, and they are all equal candidates. Order of 
>>> functions are irrelevant.
>>
>> It could work identically to how D functions today. A 'new()' 
>> constructor would be part of the root Object classes are 
>> derived of, and structs would have an implicit 'new()' 
>> constructor.
>
>  But new wouldn't be a constructor then would it? It would 
> still be based on allocating memory that's optionally 
> different. Constructor and allocation are two different steps; 
> And for it to seamlessly go from one to another defaults to 
> having a set default constructor. Let's assume...
>
>  class Object {
>    this new() {
>    //allocate
>      return defaultConstructor();
>    }
>    this defaultConstructor() {}
>  }
>
>  Now in order to make a constructor (and then destructor) you 
> either can:
>
>  A) overload or use 'defaultConstructor', which would be 
> publicly known
>  B) overload new to do allocation the same way and call a 
> different constructor and specifically add a destructor to make 
> sure it follows the same lines.
>  C) overload new to call the default allocator and then call a 
> different constructor
>
>  Now assuming you can make a different constructor by name, you 
> then have to be able to specify a destuctor the same way for 
> consistancy.
>
>  class CustomType {
>    this MyAwesomeConstuctor();
>    void MyAwesomeDestructor();
>  }
>
>  Same problem, how do you tell it ahead of time without 
> completely rewriting the rules? leaving it as 'this' and 
> '~this' are simple to remember and work with, and factory 
> functions should be used to do a bulk of work when you don't 
> want the basic/bare minimum.

Sorry, I don't understand what you're getting it. I suspect that 
you're interpreting his proposal in a completely different way 
than I am, and then trying to expose the flaws in your 
interpretation of the proposal, and then I can't follow it 
because my interpretation doesn't have those flaws :)