I fear there could be a long parade of these "How about Go's ____" topics, but anyway, here goes...

In Go (from what I understand), a struct is stack allocated with
   x := Struct();
and heap allocated with
   x := &Struct();

For D that would be
   auto x = Struct(); // stack
   auto x = &Struct(); // heap
And for D classes one could use
   auto x = Class(); // on the heap
   auto x = *Class(); // on the stack
For arrays
   auto x = &float[14];  // heap
   auto x = &float[](10,20)  // heap
   auto x = float[14];  // alt form of fixed size stack array?
For AAs
   auto x = &float[int];  // heap
   auto x = float[int]; // stack

Mostly just a syntax bikeshed, but this seemed like a nice way to
eliminate the "new" syntax that wasn't mentioned previously.
They also kind of round out the declaration possibilities so that all
these built-ins can be declared as auto or as literals. For instance,
a function that needs a 10 element scratch array passed in could be
called like:
       foo(A,B, float[10][]);
equivalent to
       float[10] tmp;
       foo(A,B, tmp[]);

I haven't really understood Dimscha's request for a templatized constructor, though.  Maybe this won't help there.

--bb

Bill Baxter Wrote:

> I fear there could be a long parade of these "How about Go's ____"
> topics, but anyway, here goes...
> ....
> Mostly just a syntax bikeshed, but this seemed like a nice way to
> eliminate the "new" syntax that wasn't mentioned previously.
> They also kind of round out the declaration possibilities so that all
> these built-ins can be declared as auto or as literals. For instance,
> a function that needs a 10 element scratch array passed in could be
> called like:
>        foo(A,B, float[10][]);
> equivalent to
>        float[10] tmp;
>        foo(A,B, tmp[]);


'... but this seemed like a nice way to eliminate the "new" syntax that wasn't mentioned previously.'

Somewhat related to this post ...

Currently in my D projects I use static opCall to eliminate "new" (at least for
classes) such as:

class Foo
{
  int x;
  Foo( int x) { this.x = x; }
  static Foo opCall( int x) { return new Foo( x); }
}

I'm not sure if this considered good D style of not (please advise), but it does eliminate having to type new all the time to allocate and construct new Foo's.

However, for consistency, I find myself often typing in static opCall boiler-plate code
when creating a new class definition even for classes which few instances are
ever created in the wild.  In some cases, then, more overall keystrokes are
incurred just to save the infrequent new keyword when instantiating the class.

Analysing the break-even point (minimum number of new's to save) for the
static opCall keystroke overhead is (at least in this case) .. hmm .. let's see ...

"new" is 3 characters but at least one whitespace separator is needed so that makes 4 characters "new ".

Now the following comparison text (edited in fixed-width font, 1st line is 50 chars; 2nd is 48):

static Foo opCall( int x) { return new Foo( x); }
new new new new new new new new new new new new

Whilst I like the idea of getting rid of new keyword, I must admit that on the balance I generally don't save any keystrokes using the static opCall instrument.

btw.  My thinking for getting rid of new keyword came from some experience
with Scala case classes and companion classes (Object in Scala parlance).
From what I understand/remember, "Object" is Scala's way of getting rid of "static" in
relation to class member variables and methods.  In some ways, D opCall some analogy
with these Scala idioms.

What do others think?

Justin Johansson

Justin Johansson Wrote:
> Currently in my D projects I use static opCall to eliminate "new" (at least for
> classes) such as:
> 
> class Foo
> {
>   int x;
>   Foo( int x) { this.x = x; }
>   static Foo opCall( int x) { return new Foo( x); }
> }
> 
> I'm not sure if this considered good D style of not (please advise), but it does eliminate having to type new all the time to allocate and construct new Foo's.
> 
> However, for consistency, I find myself often typing in static opCall boiler-plate code
> when creating a new class definition even for classes which few instances are
> ever created in the wild.  In some cases, then, more overall keystrokes are
> incurred just to save the infrequent new keyword when instantiating the class.
> 
> Analysing the break-even point (minimum number of new's to save) for the
> static opCall keystroke overhead is (at least in this case) .. hmm .. let's see ...
> 
> "new" is 3 characters but at least one whitespace separator is needed so that makes 4 characters "new ".
> 
> Now the following comparison text (edited in fixed-width font, 1st line is 50 chars; 2nd is 48):
> 
> static Foo opCall( int x) { return new Foo( x); }
> new new new new new new new new new new new new
> 
> Whilst I like the idea of getting rid of new keyword, I must admit that on the balance I generally don't save any keystrokes using the static opCall instrument.
> 
> btw.  My thinking for getting rid of new keyword came from some experience
> with Scala case classes and companion classes (Object in Scala parlance).
> From what I understand/remember, "Object" is Scala's way of getting rid of "static" in
> relation to class member variables and methods.  In some ways, D opCall some analogy
> with these Scala idioms.
> 
> What do others think?
> 

I neglected to say also that my usage of static opCall for classes is mostly in relation
to immutable "value classes".  If there's already a precomputed instance of the same
class with the same constructor parameters my static opCall returns the precomputed
instance and not a new instance.  *In this case*, it's not a matter of saving keystrokes
but a reflection of my design so I guess that makes my usage of static opCall more
of a necessity.

Justin

> In Go (from what I understand), a struct is stack allocated with
>    x := Struct();
> and heap allocated with
>    x := &Struct();

It's a nice trick, but I don't find it intuitive. Getting address of an object (re)allocates it? Literal that has different address each time?

On Thu, Nov 12, 2009 at 5:32 PM, xx <xx@xx.com> wrote:
>> In Go (from what I understand), a struct is stack allocated with
>>    x := Struct();
>> and heap allocated with
>>    x := &Struct();
>
> It's a nice trick, but I don't find it intuitive. Getting address of an object (re)allocates it? Literal that has different address each time?

I look at it more as taking the address of the type, which is currently meaningless, then passing that some constructor args.

But good point... the syntax is ambiguous with taking the address of
the constructed value literal.
I guess that would force you to add a new precendence rule.  So to
actually take the address you'd need &(Struct()).

I like it less now.

--bb