What is the rationale for retaining the use of the * operator for pointers (if any)?   It introduces another meaning for * besides multiplication that is context dependant.  I personally have always found it rather unintuitive, and prefer the semantics of a reference but without it's declarator syntax.

So instead of "int* p;"  Why not just simply use "ref p;"?  Which behaves like: "int& p;"?  I've noticed that people get easily confused by more than one level of indirection.

Also, why does D bother using the keyword "template"?  Instead of:

template Foo(T) { }

Why not:

Foo(type T) { } // Kind of the opposite of void. C++ uses typename.

The syntax for specialization also seems a bit unintuitive to me.  I would think this is more clear:

Foo(type T) { ... }   // Function Foo for any arbitrary type
Foo(type T[]) { ... } // Function Foo for any arbitrary array type
Foo(char C) { ... }   // Function Foo for the type char
Foo(char C[]) { ... } // Function Foo for an array of type char

That makes it clear that it's just like an ordinary function, but it's input is for arbitrary types and is less typing.  Any C programmer could probably pick that up in an instant and not even have to ever hear the word "template."

The problem then, is that they have to be explicitly instantiated.  How come?

I have often wondered what would happen if you change
unary & in C to unary @
and unary * to $

would remove the

int func( int * p, int * q ) {
    return *p/*q;  /* compiles but buggy :) */
}

bug ( only returns *p ?)

"Garen" <garen_nospam_@wsu.edu> wrote in message news:b0l0sf$fcn$1@digitaldaemon.com...
> What is the rationale for retaining the use of the * operator for pointers (if any)?   It introduces another meaning for * besides multiplication
that
> is context dependant.  I personally have always found it rather unintuitive, and prefer the semantics of a reference but without it's declarator syntax.
>
> So instead of "int* p;"  Why not just simply use "ref p;"?  Which behaves like: "int& p;"?  I've noticed that people get easily confused by more
than
> one level of indirection.
>
> Also, why does D bother using the keyword "template"?  Instead of:
>
> template Foo(T) { }
>
> Why not:
>
> Foo(type T) { } // Kind of the opposite of void. C++ uses typename.
>
> The syntax for specialization also seems a bit unintuitive to me.  I would think this is more clear:
>
> Foo(type T) { ... }   // Function Foo for any arbitrary type
> Foo(type T[]) { ... } // Function Foo for any arbitrary array type
> Foo(char C) { ... }   // Function Foo for the type char
> Foo(char C[]) { ... } // Function Foo for an array of type char
>
> That makes it clear that it's just like an ordinary function, but it's
input
> is for arbitrary types and is less typing.  Any C programmer could
probably
> pick that up in an instant and not even have to ever hear the word "template."
>
> The problem then, is that they have to be explicitly instantiated.  How come?
>
>
>
>

"Garen" <garen_nospam_@wsu.edu> wrote in message news:b0l0sf$fcn$1@digitaldaemon.com...
> What is the rationale for retaining the use of the * operator for pointers (if any)?   It introduces another meaning for * besides multiplication
that
> is context dependant.  I personally have always found it rather unintuitive, and prefer the semantics of a reference but without it's declarator syntax.
>
> So instead of "int* p;"  Why not just simply use "ref p;"?  Which behaves like: "int& p;"?  I've noticed that people get easily confused by more
than
> one level of indirection.

Because how do you tell the difference between manipulating the pointer and manipulating what it's pointing to?  We'd need some kind of way to differentiate.

> Also, why does D bother using the keyword "template"?  Instead of:
>
> template Foo(T) { }
>
> Why not:
>
> Foo(type T) { } // Kind of the opposite of void. C++ uses typename.

Because that looks just like a K&R function definition, and very similar to a function call.  I like Burton Radon's syntax better.

> The syntax for specialization also seems a bit unintuitive to me.  I would think this is more clear:
>
> Foo(type T) { ... }   // Function Foo for any arbitrary type
> Foo(type T[]) { ... } // Function Foo for any arbitrary array type
> Foo(char C) { ... }   // Function Foo for the type char
> Foo(char C[]) { ... } // Function Foo for an array of type char
>
> That makes it clear that it's just like an ordinary function, but it's
input
> is for arbitrary types and is less typing.  Any C programmer could
probably
> pick that up in an instant and not even have to ever hear the word "template."

I agree that genericism should be at the core of the language, not a bolt-on.  Burton Radon's syntax is closer to being ideal.

> The problem then, is that they have to be explicitly instantiated.  How come?

I'll let Walter field that one.

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> writes:

> I have often wondered what would happen if you change
> unary & in C to unary @
> and unary * to $
>
> would remove the
>
> int func( int * p, int * q ) {
>     return *p/*q;  /* compiles but buggy :) */
> }
>
> bug ( only returns *p ?)

Actually, doesn't compile (missing semicolon...)

But I see, _that's_ why every style guide recommends that you leave a space around the arithmetic operators, as in (*p / *q), and _not_ because of the increased readability? Right? :)

-Antti

Sean L. Palmer wrote:
> 
> Because how do you tell the difference between manipulating the pointer and manipulating what it's pointing to?  We'd need some kind of way to differentiate.
> 

Most of the time someone wants to manipulate what it's pointing to I think.
To manipulate the "pointer" itself, you could just use the address-of
operator &, or perhaps even treat it as a property of a reference like
e.g.:
ref int a;

a.addr++;

Which I'd think is much clearer than:
*p++;

Which then to make sense of, requies that one knows the precedence of the operators * and ++.  Not good form, IMO.

>> Also, why does D bother using the keyword "template"?  Instead of:
>>
>> template Foo(T) { }
>>
>> Why not:
>>
>> Foo(type T) { } // Kind of the opposite of void. C++ uses typename.
> 
> Because that looks just like a K&R function definition, and very similar to a function call.  I like Burton Radon's syntax better.
> 

K&R function definitions were much uglier:
void Foo(a,b,c)
int a;
char b;
float c;
{
 ...
}

The more concise form and prototyping them came from C++.  Seems more readable to me than writing out the keyword template all over.

...
> Burton Radon's syntax is closer to being ideal.

Why?

"Antti Sykari" <jsykari@gamma.hut.fi> wrote in message news:864r81o6mr.fsf@hoastest1-8c.hoasnet.inet.fi...
> "Mike Wynn" <mike.wynn@l8night.co.uk> writes:
>
> > I have often wondered what would happen if you change
> > unary & in C to unary @
> > and unary * to $
> >
> > would remove the
> >
> > int func( int * p, int * q ) {
> >     return *p/*q;  /* compiles but buggy :) */
> > }
> >
> > bug ( only returns *p ?)
>
> Actually, doesn't compile (missing semicolon...)

o.k. yes I forgot to put a ; after the comment, still it can take hours to
work out why things like that don't compiler
even experianced programmers get into those situations when you can't see
the wood for the trees, when a missing ';'
causes the compiler to report an error 1 or 2 lines past the missing ';'

and yes  my syntax highlighting editor displays it correctly, but not everyone uses one, and if you are generating your code then you can introduce this without realising it.

>
> But I see, _that's_ why every style guide recommends that you leave a space around the arithmetic operators, as in (*p / *q), and _not_ because of the increased readability? Right? :)

'/' do not require spaces, so it should be valid to not put a space under
all conditions
style should not be required for correct function. (unless your using
python)

int func( int * p, int * q ) {
     return *p/*q;  /* compiles but buggy :) */;
}

"Garen Parham" <garen_nospam_@wsu.edu> wrote in message news:b0m3fu$12af$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> >
> > Because how do you tell the difference between manipulating the pointer and manipulating what it's pointing to?  We'd need some kind of way to differentiate.
> >
>
> Most of the time someone wants to manipulate what it's pointing to I
think.
> To manipulate the "pointer" itself, you could just use the address-of operator &,

Bzzt... &address-of generates a rvalue pointer;   you can't change it.

> or perhaps even treat it as a property of a reference like
> e.g.:
> ref int a;
>
> a.addr++;
>
> Which I'd think is much clearer than:
> *p++;

But it's not clearer than the actual C equivalent,
p++;

Myself I'd use
++p;
instead.


> Which then to make sense of, requies that one knows the precedence of the operators * and ++.  Not good form, IMO.

Of course you have to know the precedence table.  In order to be able to call yourself a programmer of a given language, you must demonstrate having learned the precedence table.

> >> Also, why does D bother using the keyword "template"?  Instead of:
> >>
> >> template Foo(T) { }
> >>
> >> Why not:
> >>
> >> Foo(type T) { } // Kind of the opposite of void. C++ uses typename.
> >
> > Because that looks just like a K&R function definition, and very similar to a function call.  I like Burton Radon's syntax better.
> >
>
> K&R function definitions were much uglier:
> void Foo(a,b,c)
> int a;
> char b;
> float c;
> {
>  ...
> }
>
> The more concise form and prototyping them came from C++.  Seems more readable to me than writing out the keyword template all over.
>
> ...
> > Burton Radon's syntax is closer to being ideal.
>
> Why?

It integrates the types in where they're used.  Something like:

void Swap(inout $T a, inout $T b)
{
    $T temp = a; a = b; b = temp;
}

P.S. why is there no swap, min, max, abs builtin to D?  These are so common and basic you might as well make operators for them.

"Garen" <garen_nospam_@wsu.edu> wrote in message news:b0l0sf$fcn$1@digitaldaemon.com...
> What is the rationale for retaining the use of the * operator for pointers (if any)?   It introduces another meaning for * besides multiplication
that
> is context dependant.  I personally have always found it rather unintuitive, and prefer the semantics of a reference but without it's declarator syntax.
>
> So instead of "int* p;"  Why not just simply use "ref p;"?  Which behaves like: "int& p;"?  I've noticed that people get easily confused by more
than
> one level of indirection.

D retains the * notation for pointers so that use of pointers will stand out in the code. Most D code will not need to use pointers at all. D doesn't support the int& reference notation, because references are handled by other methods.

> Also, why does D bother using the keyword "template"?  Instead of:
>
> template Foo(T) { }
>
> Why not:
>
> Foo(type T) { } // Kind of the opposite of void. C++ uses typename.
>
> The syntax for specialization also seems a bit unintuitive to me.  I would think this is more clear:
>
> Foo(type T) { ... }   // Function Foo for any arbitrary type
> Foo(type T[]) { ... } // Function Foo for any arbitrary array type
> Foo(char C) { ... }   // Function Foo for the type char
> Foo(char C[]) { ... } // Function Foo for an array of type char
>
> That makes it clear that it's just like an ordinary function, but it's
input
> is for arbitrary types and is less typing.  Any C programmer could
probably
> pick that up in an instant and not even have to ever hear the word "template."


Templates in D are more than just functions. An entire group of declarations can be wrapped in a template block, conceptually like wrapping a group in a class block.

> The problem then, is that they have to be explicitly instantiated.  How come?

Explicit instantiation is an enormous simplification, both conceptually and practically.

Sean L. Palmer wrote:
> 
> Bzzt... &address-of generates a rvalue pointer;   you can't change it.
> 

Sure you can, you just..do it. :)  Though, maybe it's not a good idea but it wasn't what I was getting at.

> 
> But it's not clearer than the actual C equivalent,
> p++;
> 
> Myself I'd use
> ++p;
> instead.
> 

I do that too, but I think thats another unnecessary artifact (difference between postfix and prefix -- only one needed I think.)

> 
> Of course you have to know the precedence table.  In order to be able to call yourself a programmer of a given language, you must demonstrate having learned the precedence table.
> 

I'd expect just about anyone to be able to know the precedence between the basic arithmetic operators (*, /, +, -) since it's taught in gradeschool (I should hope) but * and ++ or -- are language idiosyncracies.  Why raise an artificial barrier where none is needed?  (Granted, it may not seem that significant.)  The built-in property of addr seems pretty straightforward to me.

> 
> It integrates the types in where they're used.  Something like:
> 
> void Swap(inout $T a, inout $T b)
> {
>     $T temp = a; a = b; b = temp;
> }
> 

Looks similar in form to the suggestion I had with using a keyword like "type" except here it's $.  I don't think I saw anything like that on the web page though..  Something floating around here in the NG I missed?

> P.S. why is there no swap, min, max, abs builtin to D?  These are so common and basic you might as well make operators for them.

Hmm..  e.g. min(a,b)?  Wonder if a built-in swap might allow some optimizations not as easily done by using a template or basic function.

Walter wrote:
> 
> D retains the * notation for pointers so that use of pointers will stand out in the code. Most D code will not need to use pointers at all. D doesn't support the int& reference notation, because references are handled by other methods.
>

Dereferencing pointers using * stands out, but the way they are declared is still confusing I think.  A hybrid approach of:

ref int a;

*a = whatever

Could retain the easier-to-spot use of * for dereferencing.  Seems a bit non-orthogonal to 'alias' though..

> 
> Templates in D are more than just functions. An entire group of declarations can be wrapped in a template block, conceptually like wrapping a group in a class block.
> 

I only chose functions there as an illustrate example.  With a "block"
 are you thinking of something like:

type T {
.. // all code in here parameterized by T
}
?

> 
> Explicit instantiation is an enormous simplification, both conceptually and practically.
> 

In ADA I didn't find it of much value and liked it being implicit in C++. In what sense is it simpler?  Easier to implement?


Btw I think D looks really neat, save for the declarator syntax.  Way to go. :)