Consistency, Templates, Constructors, and D3

[F i L]

Era Scarecrow wrote:
>  I'm sure in C# that all structs and classes are heap allocated 
> (It takes after C++ very likely) that's the simplest way to do 
> it. You can do that in C++ as well, but other than having to 
> declare it a pointer first. In C++ they made structs 'classes 
> that are public by default' by it's definition I believe. 
> Considering how C++ is set up that makes perfect sense.

C# structs are allocated on the stack when they can be. In 
certain cases (they're class fields, they're boxed, etc..) 
they're heap allocated.


> By looking at newFoo I'd say a class; But if like in C# I'm 
> sure you can't tell the difference (But C++ with the pointer 
> you can).

the 'auto' keyword kind negates the 'Type*' distinction. My point 
here is that you pretty much have to look up the type definition 
(or a tooltip) to understand what you're working with when 
factory functions are involved.


> And for factory functions I'd put them inside the struct/class, 
> unless I had a compelling reason not to.
>
>   class Record {
>     static Record newRecord(string options) {
>       Record rec = new Record();
>       // stuff building the complex record
>       return rec;
>     }
>   }

The result is the same weather they're inside or outside a class, 
because, when used, all the coder sees is the function name to 
know about what it's returning.

In D there is a difference between structs and classes beyond 
what's in C++. The 'new' keyword helps us understand what kind of 
object is being created, and I enjoy that. However, my argument 
is in favor of consistency because right now factory-functions, 
which _are_ used a lot, completely hide that distinction on top 
of being inconsistent with "normal" type construction.


>  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?

I'm sure this case has an easy solution. How about:

     struct Foo {
         this new() { ... } // constructor
         this() { ... } // postblit
     }


>  Only if you start getting creative can it begin to get 
> confusing;

And I have to completely disagree with you here. Memory Pools are 
used everywhere in performance-critical code which needs a 
dynamic array of objects. At least half of all the "allocation" 
in game engines is done through factory functions that recycle 
objects.

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".


>  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.

This could work in our favor, because instead of 'new' we could 
use 'alloc' (or something like that) while still encouraging 
'new'. Which means structs could provide a parameter-less new() 
constructor:

     class Foo {
         float x;
         // no constructor
     }

     auto f = Foo.alloc();
     assert(f.x == float.nan);

     ---

     struct Point {
         float x, y;
         this new() { x = 0; y = 0; }
         this new(float x, float y) { ... }
     }

     auto a = Point.new();
     auto b = Point.new(1, 2);
     assert(a.x == 0.0f);