www.digitalmars.com         C & C++   DMDScript  

D - in,out,inout: new sematic proposal

reply Farmer <itsFarmer. freenet.de> writes:
The design goals of D look really promising to me. [But ...]

Lately, I've seen a lot of complaints about the in/out semantic for D-
functions. So I hope to provide a clean, easy to understand/maintain, bug 
preventing and efficient way of parameter passing.

Note:
All my assumptions are based on the current D spec and the DMD 0.46 
compiler.

All compiler implemention details that are mentioned in this proposal, are 
only meant to clarifie the semantic. Programmers (that includes compiler 
writers) need not care about these details. 



Hint: It might be better to read this post by starting from the end 
(there's the summary).
      It might be best to read this post, not at all :-)
     


Enough talking, here it goes:



1a.) primitive types - in

By primitive types I mean, int, shorts,char, float and pointers, etc.
Primitive types are considered as value types.

Semantic: The function receives a value, this value cannot be modified by 
the function.

D: void foo(in short var)
translates to 
C: void foo(const short var)

Value types that are passed as in-parameters to functions cannot be changed 
within the function.

Rationale: I assume that the only reason for the current semantic in C is: 
Parameters were (when C was invented) pushed onto the stack, and 
programmers could reuse the already allocate stack space, so non-optimizing 
compilers will produce better code.

Today even the worst optimizing compiler (sth. like Borlands RAD style C++-
Compiler) will produce identical code for this example:

C-code:
void foo(int parm)
{
   if (parm < 0)
    	parm=47;     // provide some default value for further use
}

void foo(const int parm)       
{
   int maxlines=parm;
   if (parm < 0)
    	maxlines=47; // provide some default value for further use
}


1b.) primitive types - out/inout

D: void foo(out short var)

would translate to 
C: void foo(short* var)
or
C++: void foo(short var&)

out: The function returns a value to the callee. 

inout: The function gets a value that the function can modify.

Note: The difference between out and inout is well documented in Walter's 
spec.


Note about pointers: 
The in/out/inout storage class (word taken from the D spec) ALWAYS refers 
to the physical value of a pointer (that stuff that C programmers tend to 
cast to an int type and back ;-).
One might want to have some more control of the stuff referenced by  
pointers, but I say NO.
Rationale: Pointers are a minor feature of D. Pointers feel right for C and 
C++ (I like them there). But in D they are much more bug prone; you would 
not use pointers in a function-interface, anyway. So I just don't care much 
about them.



2a.)fixed sized arrays - in

Fixed sized arrays are value types, so the in/out/inout semantic is the 
same as for primitive types.

D: void foo(in short[5] var)
translates to
C: void foo(const short* var)

D: 
void foo(in short[5] var)
{
   var[2]=5;    	// error: 'var' cannot be an lvalue
}


2b.)fixed sized arrays - out/inout

D: void foo(out short[5] var)
translates to
C: void foo(short* const var)    

example:
D: 
void foo(out short[5] var)
{
   var[2]=5;    	// ok;
   short[5] tmp;
   var[]=tmp[];    	// ok, since D compiler makes a copy of 'tmp', right?
}

Note: According to the DMD 0.46 version the out and inout attribute is not 
allowed for fixed sized arrays. (waste of keywords, in my opinion - it's 
there so use it!)


3a.) structs - in
Structs are value types, so the semantic of in,out,inout is same as for 
primitive types and fixed sized arrays.

Note: All value types can be allocated on the stack. DMD Compiler (V0.46) 
allocates structs and fixed sized arrays onto the stack. So I suppose, 
Walter wants them to be value types.   

struct Point
{
   int x,y;
   void setX(int x)
   {this.x=x;} 
}
D: void foo(in Point var)
translates to
C: void foo(const Point* var)
or
C++: void foo(const Point& var)

Rationale: 
[I can hardly think of a case where 
C++: void foo(Point var)
is useful, when you see such a declaration, it is due to lazyness of (some) 
C++-programmers. Why would anyone want to pay the costs of copying a 
struct, when
C++: void foo(const Point& var)
provides the same safety? (Maybe one could save one indirection in the 
function body ? But I don't think that this could make code runs faster.)]
In D (with this proposal) in,out and inout, DOES NOT specify whether 
parameter passing is by reference or value. The compiler just picks the 
most efficient one that complys with semantic that belongs to the storage 
class attribute.

(Un)fortunately there is a little problem for current D:
The function can call a function of a struct, which could change the 
struct.
This is not a big issue, there a several ways to tackle this problem, e.g.:
-ignore it: compiler does not ensure constness, the programmer is paid to 
take care of this. ( would be perfectly acceptible for an alpha compiler, I 
think)
-let the programmer flag function members of structs, whether they are 
const or not (similar to C++). 
-let the compiler figure it out itself 
-do not allow functions for structs at all (classes are better for 
functions anyway, but struct might be faster due to stack allocation)

I do not address this issue here, because first I want Walter answer some 
questions regarding "const" at the end of this post.


3b.) structs - out/inout

struct Point
{
   int x,y;
}

D: void foo(inout Point var)
translates to
C: void foo(Point* var)
or
C++: void foo(Point& var)

No explanation, you already got the point, for sure.


4a.)Objects - in

Objects are reference types. 
The storage modifiers apply to the reference handle, since you can only 
pass reference handles arround (you cannot copy a Object, just its handle), 
so you are always working on the handle, except when using the '.'operator.

Note: Objects are always allocated in the garbage collected heap.


class Logger
{}
D: void foo(in Logger o)
translates to 
C++: void foo(Logger& const o)

Rationale:

Highly paid Java-programmers often write the following (but not me, I'm 
lowly paid ;-)

Java (with non-OO extensions):
class Result
{
   int value;
}

/**
 * returns a Result object from the Database
 *  return 0 if error;  7 if strange error; 1 on success
 */
int getFromDB(Result o)
{
    o=new Result();
    o.value=47;                     // BUG; callee's object is not changed!
    return 1;
}

in D:
int getFromDB(in Result o)
{
   o=new Result();      // compiler error: 'o' cannot be an lvalue,
   o.value=47;
   return 1;
}


4b.)Objects - out/inout

class Logger
{}
D: void foo(out Logger o)
translates to 
C++: void foo(Logger*& o)


Rationale:
-Allows to do sth. that Java cannot do ;-)
Return multiple new objects from a function.

-There is currently no concept for const for classes in D anyway. So there 
is no other way to do it.



5a.) dynamic/assoziative Arrays - in 
Dynamic Arrays are kind of reference types. (They are not true reference 
types) 

Note: The elements of dynamic/assoziative Arrays is always allocate in the 
garbage collected heap. A very small part, namely the length is allocate 
onto the stack.


D: void foo(in list[])
translates to
C:  void foo(listData* const, const int listLength)

Rationale:
Dynamic Arrays are kind of reference type, so in/out/inout has the same 

arrays are Objects, but they are not (in D). With the proposed parameter 
passing semantic, passing arrays will have the same semantic as in Java or 

or return an array with a changed length). So these programmers will feel 
at home.

I understand that from a purly practical viewpoint, one might wish to make 
the entire list const. But having a clean language will prove to be more 
worthy.
 

5b.) dynamic/assoziative Arrays - out/inout

D: void foo(out list[])
translates to
C++:  void foo(listData*, int listLength&)


SUMMARY
-------


value types: primitive types, pointers, fixed sized arrays and structs:
-----------
'in': Callee 'sends' a value to the function. The function can NEITHER 
return a changed value to the callee, NOR can it change the local copy of 
this value that might exist for some combinations of  value type and 
compiler implementation.

'out': Function returns a value to the callee. The callee provides the 
memory into which the function stores the return value.

'inout': Callee 'sends' a value to the function. The function can read and 
change value. The function operates directly on the memory, which the 
callee uses to 'send' the value to the function.


reference types: objects, dynamic/assoziative Arrays ("kind of" only)
--------------- 

'in': Callee 'sends' a reference handle to the function. The function can 
can change the referenced element(s), but not it cannot change the 
reference handle. (Consequently the function cannot return a new a 
reference handle object to the callee.)

'out': Function returns a reference handle to the callee. (Consequently the 
function must return a new reference object to the callee.)

'inout': Callee 'sends' a reference handle to the function. The function 
can read and change the referenced element(s). Furthermore it can change 
the reference handle. (Consequently the function can return a new reference 
object to the callee.)


Learning rule
-------------
The storage specifiers in, out and inout always refer to the lowest 
possible level of indirection, an assembler programmer can think of. 


Learning advice for non-programmers*
-------------
Think up the parameters of functions, as it is taught to students in their 
university lessons (with in, out and maybe in out, of course).

Never think about references and constness, as  C++-programmers do ! 
Never think about all that wired stuff that is mentioned in this proposal !

Now use the conceived attributes straight with you D-function,  it should 
work. (Except for fixed sized arrays, because students are taught to not 
use them) 



languages, so these instruction will not work for them.



--------------------------------------------------------------------------




Questions about "C++ const" to Walter:
-------------------------------------

Though I did not find anything in the D spec (this night) regarding "C++ 
const" , I do remember that you (Walter) said, that the "const" concept of 
C++ does not really pay off - so you do not want to provide a similar 
concept for D. My problem is, that I did not get the point what the bad 
points of "C++ const" are EXACTLY.

Here are my assumptions about bad points of the "C++ const" concept that 
you might have. 

1. Const does not pay off, because to few C++ programmers actually use it. 
You can not use const objects with frameworks, because they have to many 
non-const functions.

2. Const does not pay off, because when programming with large 
frameworks/codebase, too many functions are inherently non-const: A 
reference to a const object is almost useless, because at some point you 
simply must call one of these non-const functions. So, you end up using 
const casts all the time. (alternatively you can store two versions of 
every reference)

3. It is too disheartening that const inherently is not usefull for good 
optimizations.

3. It is too disheartening that const cannot be used for optimizations, 
because the C++ semantic of const/the common programming practice with 
const in C++, prevent any optimizations.

4. Const clutteres the declarations of functions and reference types too 
much.

5. Const complicates the rules for function overloading, function 
overriding, class inheritence and interface inheritance, etc. too much.  

6. It is too difficult to make a compiler that checks for constness.



Have a nice D.
Oct 30 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
Interesting proposal.
Yet, I think it leaves several things unanswered.
See below.


"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns92B816E513F51itsFarmer 63.105.9.61...

 The design goals of D look really promising to me. [But ...]

 Lately, I've seen a lot of complaints about the in/out semantic for D-
 functions. So I hope to provide a clean, easy to understand/maintain, bug
 preventing and efficient way of parameter passing.

 Note:
 All my assumptions are based on the current D spec and the DMD 0.46
 compiler.

 All compiler implemention details that are mentioned in this proposal, are
 only meant to clarifie the semantic. Programmers (that includes compiler
 writers) need not care about these details.


*snap*

 1a.) primitive types - in

 By primitive types I mean, int, shorts,char, float and pointers, etc.
 Primitive types are considered as value types.

 Semantic: The function receives a value, this value cannot be modified by
 the function.

 D: void foo(in short var)
 translates to
 C: void foo(const short var)

 Value types that are passed as in-parameters to functions cannot be


changed

 within the function.

 Rationale: I assume that the only reason for the current semantic in C is:
 Parameters were (when C was invented) pushed onto the stack, and
 programmers could reuse the already allocate stack space, so


non-optimizing

 compilers will produce better code.

 Today even the worst optimizing compiler (sth. like Borlands RAD style


C++-

 Compiler) will produce identical code for this example:

 C-code:
 void foo(int parm)
 {
    if (parm < 0)
     parm=47;     // provide some default value for further use
 }

 void foo(const int parm)
 {
    int maxlines=parm;
    if (parm < 0)
     maxlines=47; // provide some default value for further use
 }


Comparing those two functions, I think the first one is cleaner. You don't
need to give two names (variables) to the same concept, which you can later
use intermixed. And you can avoid an extra line. I think this is a good
example for allowing changing privitive types as "in" parameter.



 1b.) primitive types - out/inout

 D: void foo(out short var)

 would translate to
 C: void foo(short* var)


You mean
void foo(short* const var)


 or
 C++: void foo(short var&)

 out: The function returns a value to the callee.

 inout: The function gets a value that the function can modify.

 Note: The difference between out and inout is well documented in Walter's
 spec.


*snap*

 2a.)fixed sized arrays - in

 Fixed sized arrays are value types, so the in/out/inout semantic is the
 same as for primitive types.

 D: void foo(in short[5] var)
 translates to
 C: void foo(const short* var)


You mean
void foo(const short* const var)


 D:
 void foo(in short[5] var)
 {
    var[2]=5;    // error: 'var' cannot be an lvalue
 }


 2b.)fixed sized arrays - out/inout

 D: void foo(out short[5] var)
 translates to
 C: void foo(short* const var)

 example:
 D:
 void foo(out short[5] var)
 {
    var[2]=5;    // ok;
    short[5] tmp;
    var[]=tmp[];    // ok, since D compiler makes a copy of 'tmp', right?
 }

 Note: According to the DMD 0.46 version the out and inout attribute is not
 allowed for fixed sized arrays. (waste of keywords, in my opinion - it's
 there so use it!)



Since you can change array contents of "in" parameters, what more could
"out" do for fixed size arrays?



 3a.) structs - in
 Structs are value types, so the semantic of in,out,inout is same as for
 primitive types and fixed sized arrays.

 Note: All value types can be allocated on the stack. DMD Compiler (V0.46)
 allocates structs and fixed sized arrays onto the stack. So I suppose,
 Walter wants them to be value types.

 struct Point
 {
    int x,y;
    void setX(int x)
    {this.x=x;}
 }
 D: void foo(in Point var)
 translates to
 C: void foo(const Point* var)


You mean
void foo(const Point* const var)


 or
 C++: void foo(const Point& var)

 Rationale:
 [I can hardly think of a case where
 C++: void foo(Point var)
 is useful, when you see such a declaration, it is due to lazyness of


(some)

 C++-programmers. Why would anyone want to pay the costs of copying a
 struct, when
 C++: void foo(const Point& var)
 provides the same safety? (Maybe one could save one indirection in the
 function body ? But I don't think that this could make code runs faster.)]


*No.*

Point move(Point a, int x, int y)
{
  a.x += x;
  a.y += y;
  return a;
}

Is cleaner and *faster* than:

Point move(const Point &a, int x, int y)
{
  Point result = a;
  result.x += x;
  result.y += y;
  return result;
}


 In D (with this proposal) in,out and inout, DOES NOT specify whether
 parameter passing is by reference or value. The compiler just picks the
 most efficient one that complys with semantic that belongs to the storage
 class attribute.


I don't like this. Withouth specification, you can not rely on the different
semantic behaviour of passing by reference or value (copy). And you have to
manually *emulate* them, if you need one of them.



 (Un)fortunately there is a little problem for current D:
 The function can call a function of a struct, which could change the
 struct.
 This is not a big issue, there a several ways to tackle this problem,


e.g.:

 -ignore it: compiler does not ensure constness, the programmer is paid to
 take care of this. ( would be perfectly acceptible for an alpha compiler,


I

 think)


Acceptable for an alpha compiler, yes. For the specification, no.


 -let the programmer flag function members of structs, whether they are
 const or not (similar to C++).
 -let the compiler figure it out itself
 -do not allow functions for structs at all (classes are better for
 functions anyway, but struct might be faster due to stack allocation)

 I do not address this issue here, because first I want Walter answer some
 questions regarding "const" at the end of this post.


 3b.) structs - out/inout

 struct Point
 {
    int x,y;
 }

 D: void foo(inout Point var)
 translates to
 C: void foo(Point* var)
 or
 C++: void foo(Point& var)

 No explanation, you already got the point, for sure.


 4a.)Objects - in

 Objects are reference types.
 The storage modifiers apply to the reference handle, since you can only
 pass reference handles arround (you cannot copy a Object, just its


handle),

 so you are always working on the handle, except when using the


'.'operator.

 Note: Objects are always allocated in the garbage collected heap.


 class Logger
 {}
 D: void foo(in Logger o)
 translates to
 C++: void foo(Logger& const o)


There is no such syntax in C++. You mean
void foo(Logger& o)


 Rationale:

 Highly paid Java-programmers often write the following (but not me, I'm
 lowly paid ;-)

 Java (with non-OO extensions):
 class Result
 {
    int value;
 }

 /**
  * returns a Result object from the Database
  *  return 0 if error;  7 if strange error; 1 on success
  */
 int getFromDB(Result o)
 {
     o=new Result();
     o.value=47;                     // BUG; callee's object is not


changed!

     return 1;
 }

 in D:
 int getFromDB(in Result o)
 {
    o=new Result();      // compiler error: 'o' cannot be an lvalue,
    o.value=47;
    return 1;
 }


 4b.)Objects - out/inout

 class Logger
 {}
 D: void foo(out Logger o)
 translates to
 C++: void foo(Logger*& o)


 Rationale:
 -Allows to do sth. that Java cannot do ;-)
 Return multiple new objects from a function.

 -There is currently no concept for const for classes in D anyway. So there
 is no other way to do it.



 5a.) dynamic/assoziative Arrays - in
 Dynamic Arrays are kind of reference types. (They are not true reference
 types)

 Note: The elements of dynamic/assoziative Arrays is always allocate in the
 garbage collected heap. A very small part, namely the length is allocate
 onto the stack.


 D: void foo(in list[])
 translates to
 C:  void foo(listData* const, const int listLength)

 Rationale:
 Dynamic Arrays are kind of reference type, so in/out/inout has the same

 arrays are Objects, but they are not (in D). With the proposed parameter
 passing semantic, passing arrays will have the same semantic as in Java or



array

 or return an array with a changed length). So these programmers will feel
 at home.

 I understand that from a purly practical viewpoint, one might wish to make
 the entire list const. But having a clean language will prove to be more
 worthy.


 5b.) dynamic/assoziative Arrays - out/inout

 D: void foo(out list[])
 translates to
 C++:  void foo(listData*, int listLength&)


 SUMMARY
 -------


 value types: primitive types, pointers, fixed sized arrays and structs:
 -----------
 'in': Callee 'sends' a value to the function. The function can NEITHER
 return a changed value to the callee, NOR can it change the local copy of
 this value that might exist for some combinations of  value type and
 compiler implementation.

 'out': Function returns a value to the callee. The callee provides the
 memory into which the function stores the return value.

 'inout': Callee 'sends' a value to the function. The function can read and
 change value. The function operates directly on the memory, which the
 callee uses to 'send' the value to the function.


 reference types: objects, dynamic/assoziative Arrays ("kind of" only)
 ---------------

 'in': Callee 'sends' a reference handle to the function. The function can
 can change the referenced element(s), but not it cannot change the
 reference handle. (Consequently the function cannot return a new a
 reference handle object to the callee.)

 'out': Function returns a reference handle to the callee. (Consequently


the

 function must return a new reference object to the callee.)

 'inout': Callee 'sends' a reference handle to the function. The function
 can read and change the referenced element(s). Furthermore it can change
 the reference handle. (Consequently the function can return a new


reference

 object to the callee.)


 Learning rule
 -------------
 The storage specifiers in, out and inout always refer to the lowest
 possible level of indirection, an assembler programmer can think of.


 Learning advice for non-programmers*
 -------------
 Think up the parameters of functions, as it is taught to students in their
 university lessons (with in, out and maybe in out, of course).

 Never think about references and constness, as  C++-programmers do !
 Never think about all that wired stuff that is mentioned in this proposal


!

 Now use the conceived attributes straight with you D-function,  it should
 work. (Except for fixed sized arrays, because students are taught to not
 use them)



 languages, so these instruction will not work for them.



 --------------------------------------------------------------------------




 Questions about "C++ const" to Walter:
 -------------------------------------

 Though I did not find anything in the D spec (this night) regarding "C++
 const" , I do remember that you (Walter) said, that the "const" concept of
 C++ does not really pay off - so you do not want to provide a similar
 concept for D. My problem is, that I did not get the point what the bad
 points of "C++ const" are EXACTLY.

 Here are my assumptions about bad points of the "C++ const" concept that
 you might have.

 1. Const does not pay off, because to few C++ programmers actually use it.
 You can not use const objects with frameworks, because they have to many
 non-const functions.


What kind of framework are you refering to?


 2. Const does not pay off, because when programming with large
 frameworks/codebase, too many functions are inherently non-const: A
 reference to a const object is almost useless, because at some point you
 simply must call one of these non-const functions. So, you end up using
 const casts all the time. (alternatively you can store two versions of
 every reference)


You never ever need to store two version of the reference because of
constness.
You can always call const member functions through non-const references.


 3. It is too disheartening that const inherently is not usefull for good
 optimizations.


At least it is not bad for optimization. And it is good for other things.


 3. It is too disheartening that const cannot be used for optimizations,
 because the C++ semantic of const/the common programming practice with
 const in C++, prevent any optimizations.


Casting away const is bad, and - in any finely designed language -
unnecessary. If that is what you refer to.


 4. Const clutteres the declarations of functions and reference types too
 much.


Then, "in" clutters the declarations of functions too much.


 5. Const complicates the rules for function overloading, function
 overriding, class inheritence and interface inheritance, etc. too much.


It depends on the specification. One can make up simpler rules than C++.


 6. It is too difficult to make a compiler that checks for constness.


I doubt.


Sandor
Oct 31 2002
next sibling parent antti.sykari housemarque.fi writes:
"Sandor Hojtsy" <hojtsy index.hu> writes:

 C-code:
 void foo(int parm)
 {
    if (parm < 0)
     parm=47;     // provide some default value for further use
 }

 void foo(const int parm)
 {
    int maxlines=parm;
    if (parm < 0)
     maxlines=47; // provide some default value for further use
 }


 Comparing those two functions, I think the first one is cleaner. You don't
 need to give two names (variables) to the same concept, which you can later
 use intermixed. And you can avoid an extra line. I think this is a good
 example for allowing changing privitive types as "in" parameter.


This seems to be a matter of taste - in "Refactoring", Martin Fowler
suggests that formal parameters should not be changed.  The name of
the refactoring is "Remove Assignments to Parameters".

Antti
Oct 31 2002
prev sibling parent reply Farmer <itsFarmer. freenet.de> writes:
Subject: in,out,inout: new sematic proposal
Newsgroups: Digital Mars News:D
Followup-To: poster

Thanks, for taking the trouble to fully read my last post.
Thanks again, for catching my stupid C++-mistake 

 C++: void foo(Logger& const o)     



Unfortunately, my last post was quite misleading. Flagging any
in-parameter  as "const", so programmers cannot reuse the variablename,
is only a minor topic of my proposal. It is not what I consider as the
new semantic. 

You can actually transform the proposal to a version that does not
require  "Remove Assignments to Parameters". 
example:

struct Point { int x, y }
D:
void foo(in Point calleeVar)  
{
  printPoint(calleeVar); 
  calleeVar.x=5;        // no error, since only a local version is
  changed 
}

Compilers could still pass it by reference, by generating this C++ code:
void fooCpp(const Point& calleeVar)
{
   Point temporary=calleeVar;
   printPoint(calleeVar);
   temporary.x=5;     
}
But this would not make things easier for compiler writers, since 
compilers must check for constness, anyway. 

That said, I still favor the  "Remove Assignments to Parameters"
semantic of my proposal. I would like it for D. But I do not like it

semantic when I try to clarify some issues of my proposal. 



 D: void foo(in short[5] var)
 translates to
 C: void foo(const short* var)


 
 You mean
 void foo(const short* const var)


When I wrote "D func declaration" translates to "C func declaration."  
I do not think of translating valid D-code to valid C-code.
"Tanslates to" means, when I were compiler writer, I would emit
assembler code, the same way as it is done for that C-function
declaration. By leaving the pointer non-const, I wanted to stress the
fact, that a compiler can reuse the stack address (or register) of the
pointer variable (so, it is not truly const). So there is no performance
penalty for "Remove Assignments to Parameters". 

Both versions seem correct to me, my version is simply a bit weirder.


 



The new semantic has two major changes compared to D as implemented by
DMD 0.46. 


I.) 
The programmer cannot force the compiler to place a struct onto the
stack for parameter passing. (Actually the compiler always decides how
to shuffle parameters to and from functions, so 'out' does not mean by
reference, on RISC-cpu's the compiler might use registers to do this) 

Rationale: The compiler can better decide how to shuffle values between
functions around. (Programmers a prone to make wrong assumptions what is
the fast way to do it) 



II.)
2a.)fixed sized arrays - in

Fixed sized arrays are value types, so the in/out/inout semantic is the 
same as for primitive types.

D: void foo(in short[5] var)
translates to 
C: void foo(const short* var)

D: 
void foo(in short[5] var)
{
   var[2]=5;    	// error: 'var' cannot be an lvalue
}

FIXED sized arrays cannot be changed by the function body. 
Note: the semantic for dynamic arrays is entirely different, since they
are a kind of reference type, not a value type). 


2b.)fixed sized arrays - out/inout

D: void foo(out short[5] var)
translates to
C: void foo(short* var)    
// in my last post, I wrote C: void foo(short* const var), but I prefer
the above version (there is no semantic difference, anyway). 

example:
D: 
void foo(out short[5] var)
{
   var[2]=5;    	// ok;
   short[5] tmp;
   var[]=tmp[];    	// ok, since D compiler makes a copy of 'tmp',
   right? 
}

In the current DMD implementation it seems that 'in' means basically pass 
by value and inout/out simply means pass by reference. To get the proper 
meaning of the D function declaration, you have to first transform it to 
the corresponding C function declaration, because C-semantic of "in,out and 
inout", applys.


III.)extern (C) functions
Last time I forgot this issue.

The in, out, and inout attributes can only be applied to D functions.
Extern C, Pascal, Windows functions are actually C-Functions not 
D-Functions. So the syntax and semantic for parameters passing is
C-style. 

The compiler assures that D-types can be passed properly to C-Functions.
example
D:
extern (C) int foo(const char* s )   //'const' is allowed for C
extern (C) int foo2(char* s, int* v)
extern (C) int foo3(char* s, const int* v)

void dfunc(in char[] string, in int value)
{
   int i=foo(&string[0]);      // ok

   i=foo2(&string[0], &value); // error: 'value' cannot be use as an
   lvalue i=foo3(&string[0], &value); // ok
}




-------------------------------
Not so important stuff 





 Point move(Point a, int x, int y)
 {
   a.x += x;
   a.y += y;
   return a;
 }
 
 Is cleaner and *faster* than:
 
 Point move(const Point &a, int x, int y)
 {
   Point result = a;
   result.x += x;
   result.y += y;
   return result;
 }


When I do C++, I normally use the later version, when the function is a
public member of a class. Because, the fact that the functionbody needs
to change a lokal version of this variable is unimportant for the
callee. When I'm writing the a private method, I use the first version,

to type. 

But both versions are ugly and not really fast (a structure is returned
by value). 

Heres it is in D:

Point move(Point a, int x, int y)
{
   Point result = a;

   result.x += x;
   result.y += y;
   return result;
}

Same as in C++, does not look that bad at all.

or 'better' (at least slower, I assume)

class Point
{
private:
   int x;
   int y;
public:   
   void move(int x, int y)
   {
     this.x=x;
     this.y=y;
   }
}
Looks really good if you like OO-programming.



 In D (with this proposal) in,out and inout, DOES NOT specify whether
 parameter passing is by reference or value. The compiler just picks
 the most efficient one that complys with semantic that belongs to the
 storage class attribute.


 
 I don't like this. Withouth specification, you can not rely on the
 different semantic behaviour of passing by reference or value (copy).
 And you have to manually *emulate* them, if you need one of them.


Few programmers do like this. But specifications for programming
languages should leave as much freedom to the compiler implementers
as possible. Because different hardware-platforms have different needs. A 
good programmer can gain nothing from strict implementation rules. You 
either know how your compiler does implement certain features or you have 
no idea about your platform/compiler anyway. If you do not know your 
compiler, you cannot make the compiler produce better code. 

Explanation:
Sandor, claimed (which might be true for his compiler/platform) that
passing a struct by value (as shown in his example),  is faster than
passing it by const reference and making a local copy from it. 

I checked this with MS VC++ 6.0 SP5 (with processorpack) with the
optimizing for speed settings. Since I'm not a cpu-cycle counter, I
cannot say exactly which one is faster on an Athlon, Pentium IV or
Pentium II or ... 

But I assume that both versions have practically the same speed. 

The functionbody of the passing by reference version is larger, but the
parameter passing requires a less code. This results in a smaller
overall code size. 

The attachment contains the dissembler code for the example.



---



 1. Const does not pay off, because to few C++ programmers actually
 use it. You can not use const objects with frameworks, because they
 have to many non-const functions.


 
 What kind of framework are you refering to?


I mean all that stuff that makes up a complex real world application:
Project specific classes (the thing that is thought up by yourself and your 
team), common utility classes of your employer,
runtime library of the programming language, and additional commercial/free 
libraries.
You usually end up having a dozens of classes, hundreds of objects, all 
intermixed.
Now the question is, how often can  you use a const reference to other
objects ? (without using const_cast). 




 4. Const clutteres the declarations of functions and reference types
 too much.


 
 Then, "in" clutters the declarations of functions too much.


I assume that Walter may dislike "const" because functions in D are
already cluttered with in (optional), out, inout. 



Have a nice D.



  







begin 644 ByRefOrValue.txt




M;7!A<FEN9R!B;W1H('9E<G-I;VYS+"!T:&4 <&%S<R!B>2!R969E<F5N8V4 
M8V]D92!R97%U:7)E<R!O;F4 (G!U<V  1U!2(B!I;G-T<G5C=&EO;B!L97-S

M;W8 (&5C>"QD=V]R9"!P='( 6V5S<%T-"B\O("` ("` ("`R+B!P=7-H(&5C


































M("!S=')U8W0 4&]I;G0 ;6]V95)E9BAC;VYS="!0;VEN="8 82P :6YT(' L
M(&EN="!Y*0T*,3$Z("` >PT*,3(Z("` ("` (%!O:6YT(')E<W5L="`](&$[









M('!A<W-I;F< 8GD =F%L=64-"C$Y.B` (%!O:6YT(&UO=F5686QU92A0;VEN









`
end
Nov 01 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns92B9BDA3ECC8AitsFarmer 63.105.9.61...

 Subject: in,out,inout: new sematic proposal
 Newsgroups: Digital Mars News:D
 Followup-To: poster

 Thanks, for taking the trouble to fully read my last post.
 Thanks again, for catching my stupid C++-mistake

 C++: void foo(Logger& const o)



 Unfortunately, my last post was quite misleading. Flagging any
 in-parameter  as "const", so programmers cannot reuse the variablename,
 is only a minor topic of my proposal. It is not what I consider as the
 new semantic.

 You can actually transform the proposal to a version that does not
 require  "Remove Assignments to Parameters".
 example:

 struct Point { int x, y }
 D:
 void foo(in Point calleeVar)
 {
   printPoint(calleeVar);
   calleeVar.x=5;        // no error, since only a local version is
   changed
 }

 Compilers could still pass it by reference, by generating this C++ code:
 void fooCpp(const Point& calleeVar)
 {
    Point temporary=calleeVar;
    printPoint(calleeVar);
    temporary.x=5;
 }


Conceptually, the "generated code" should not use the calleeVar parameter in
later calls, because the local variable may change before the call. If the
optimizing compiler detects that it will not change it can still insert the
reference.

void fooCpp(const Point& calleeVar)
{
   Point temporary=calleeVar;
   printPoint(temporary); // <--- note this line
   temporary.x=5;
}

From the user and the conceptual point of view, both of your examples use
pass by value, and I agree that the compiler should be free to choose from
these two, and several other implementations of pass by value. I don't think
you have invented any new semantics. These are just different compiler
implementations for the same semantic rule.

The C++ specification includes a statement similar to (excuse me, I don't
have the specs with me now):
"The compiler implementation is free to be different from this specs, if it
can be proven that no user will ever notice the difference."
I think the same applies to D.

A problem may arise if you try to call a function from a different
compilation module.
What kind of function call should the compiler insert into the object file?
How can you guarantee that all modules calling the function will use the
same call method?
This kind of optimization seems to be possible only at link time, but
reqires compilation. This would intermix the clear sequential process of
compilation which Walter is fond of.


 But this would not make things easier for compiler writers, since
 compilers must check for constness, anyway.

 That said, I still favor the  "Remove Assignments to Parameters"
 semantic of my proposal. I would like it for D. But I do not like it

 semantic when I try to clarify some issues of my proposal.



 D: void foo(in short[5] var)
 translates to
 C: void foo(const short* var)


 You mean
 void foo(const short* const var)


 When I wrote "D func declaration" translates to "C func declaration."
 I do not think of translating valid D-code to valid C-code.
 "Tanslates to" means, when I were compiler writer, I would emit
 assembler code, the same way as it is done for that C-function
 declaration.


I see.


 By leaving the pointer non-const, I wanted to stress the
 fact, that a compiler can reuse the stack address (or register) of the
 pointer variable (so, it is not truly const). So there is no performance
 penalty for "Remove Assignments to Parameters".


I don't see how can the compiler "reuse the stack address of the pointer
variable". Reuse for what? And after reusing how would you refer to the
originaly pointed value? How is this connected to the performance penality
for "Remove Assignments to Parameters"?



 The new semantic has two major changes compared to D as implemented by
 DMD 0.46.


 I.)
 The programmer cannot force the compiler to place a struct onto the
 stack for parameter passing. (Actually the compiler always decides how
 to shuffle parameters to and from functions, so 'out' does not mean by
 reference, on RISC-cpu's the compiler might use registers to do this)

 Rationale: The compiler can better decide how to shuffle values between
 functions around. (Programmers a prone to make wrong assumptions what is
 the fast way to do it)


Well, yes.
But if user code is not affected, I don't see why you need to put his
statement to the specification at all.



 II.)
 2a.)fixed sized arrays - in

 Fixed sized arrays are value types, so the in/out/inout semantic is the
 same as for primitive types.

 D: void foo(in short[5] var)
 translates to
 C: void foo(const short* var)

 D:
 void foo(in short[5] var)
 {
    var[2]=5;    // error: 'var' cannot be an lvalue
 }

 FIXED sized arrays cannot be changed by the function body.
 Note: the semantic for dynamic arrays is entirely different, since they
 are a kind of reference type, not a value type).


If you still want immutable "in" parameters for value types, then why are we
arguing about how to specify/implement fast mutable "in" parameters?



 2b.)fixed sized arrays - out/inout

 D: void foo(out short[5] var)
 translates to
 C: void foo(short* var)
 // in my last post, I wrote C: void foo(short* const var), but I prefer
 the above version (there is no semantic difference, anyway).

 example:
 D:
 void foo(out short[5] var)
 {
    var[2]=5;    // ok;
    short[5] tmp;
    var[]=tmp[];    // ok, since D compiler makes a copy of 'tmp',
    right?
 }

 In the current DMD implementation it seems that 'in' means basically pass
 by value and inout/out simply means pass by reference. To get the proper
 meaning of the D function declaration, you have to first transform it to
 the corresponding C function declaration, because C-semantic of "in,out


and

 inout", applys.


 III.)extern (C) functions
 Last time I forgot this issue.

 The in, out, and inout attributes can only be applied to D functions.
 Extern C, Pascal, Windows functions are actually C-Functions not
 D-Functions. So the syntax and semantic for parameters passing is
 C-style.

 The compiler assures that D-types can be passed properly to C-Functions.
 example
 D:
 extern (C) int foo(const char* s )   file://'const' is allowed for C
 extern (C) int foo2(char* s, int* v)
 extern (C) int foo3(char* s, const int* v)

 void dfunc(in char[] string, in int value)
 {
    int i=foo(&string[0]);      // ok

    i=foo2(&string[0], &value); // error: 'value' cannot be use as an
    lvalue i=foo3(&string[0], &value); // ok
 }




 -------------------------------
 Not so important stuff





 Point move(Point a, int x, int y)
 {
   a.x += x;
   a.y += y;
   return a;
 }

 Is cleaner and *faster* than:

 Point move(const Point &a, int x, int y)
 {
   Point result = a;
   result.x += x;
   result.y += y;
   return result;
 }


 When I do C++, I normally use the later version, when the function is a
 public member of a class. Because, the fact that the functionbody needs
 to change a lokal version of this variable is unimportant for the
 callee. When I'm writing the a private method, I use the first version,

 to type.

 But both versions are ugly and not really fast (a structure is returned
 by value).


I don't find the first version ugly. How else would you return a structure?
Return a reference to a local structure variable?


 Heres it is in D:

 Point move(Point a, int x, int y)
 {
    Point result = a;

    result.x += x;
    result.y += y;
    return result;
 }

 Same as in C++, does not look that bad at all.



Not that bad because of what?



 or 'better' (at least slower, I assume)

 class Point
 {
 private:
    int x;
    int y;
 public:
    void move(int x, int y)
    {
      this.x=x;
      this.y=y;
    }
 }
 Looks really good if you like OO-programming.


Yes it looks good, but does a different thing. To do the same as the
examples above, it should rather be:

Point move(int xd, int yd)
{
   Point p = new Point(this);
   p.x += xd;
   p.y += yd;
   return p;
}

Now does it look good?




 In D (with this proposal) in,out and inout, DOES NOT specify whether
 parameter passing is by reference or value. The compiler just picks
 the most efficient one that complys with semantic that belongs to the
 storage class attribute.


 I don't like this. Withouth specification, you can not rely on the
 different semantic behaviour of passing by reference or value (copy).
 And you have to manually *emulate* them, if you need one of them.


 Few programmers do like this. But specifications for programming
 languages should leave as much freedom to the compiler implementers
 as possible. Because different hardware-platforms have different needs. A
 good programmer can gain nothing from strict implementation rules. You
 either know how your compiler does implement certain features or you have
 no idea about your platform/compiler anyway. If you do not know your
 compiler, you cannot make the compiler produce better code.

 Explanation:
 Sandor, claimed (which might be true for his compiler/platform) that
 passing a struct by value (as shown in his example),  is faster than
 passing it by const reference and making a local copy from it.

 I checked this with MS VC++ 6.0 SP5 (with processorpack) with the
 optimizing for speed settings. Since I'm not a cpu-cycle counter, I
 cannot say exactly which one is faster on an Athlon, Pentium IV or
 Pentium II or ...

 But I assume that both versions have practically the same speed.


Thanks for going into details. I checked the dissasembly, and it proves
that they are practically the same speed and I was wrong with the speed
comparsion.


 The functionbody of the passing by reference version is larger, but the
 parameter passing requires a less code. This results in a smaller
 overall code size.


Which may be a different issue from speed.


 1. Const does not pay off, because to few C++ programmers actually
 use it. You can not use const objects with frameworks, because they
 have to many non-const functions.


 What kind of framework are you refering to?


 I mean all that stuff that makes up a complex real world application:
 Project specific classes (the thing that is thought up by yourself and


your

 team), common utility classes of your employer,
 runtime library of the programming language, and additional


commercial/free

 libraries.
 You usually end up having a dozens of classes, hundreds of objects, all
 intermixed.
 Now the question is, how often can  you use a const reference to other
 objects ? (without using const_cast).


In C++ const can only be useful, if the framework creator, (or library
programmer), designed his system with the "const" concept in mind. For
example standard Windows API functions don't specify const for the
parameters they don't wan't to change. This makes using const with Windows
API almost impossible. For example, the first parameter of the CreateFile
function has the type of "char *", and not "const char *".  Therefore
CreateFile does not sign a contract that it will not change the first
parameter. CreateFile can change it if it likes to. So you should not pass a
string literal as a filename! Now that is *inconvinient*, at least.
But if you are creating the framework, const can be used as a contract. The
compiler could and should check that the function don't violate the contract
by changing the refered value. This can help bug-shooting at compile time.
About half of library functions can and therefore should sign the contract
to leave some parameters unmodified.  The compiler can help you find the
places when the functions violate the contract, most of which will surely be
bugs.



 4. Const clutteres the declarations of functions and reference types
 too much.


 Then, "in" clutters the declarations of functions too much.


 I assume that Walter may dislike "const" because functions in D are
 already cluttered with in (optional), out, inout.


This decalaration is ugly:
void foo(const inout a)
{
...
}
But it is ugly not because the parameter list is long. The problem seems to
be that how can an "inout" parameter be const.
The solution is different terminonlogy. The "inout" keyword was used here to
force passing by reference, but you would not like to use this reference to
change the original value. References are used not only to change the
original value. They are also usefull if you would always like to see the
current value of the reffered variable, not some old value which it had at
the time of copying. References has three semantical features:
1) you can change the original value in real-time, and
2) you can see the actual value if it was changed by somebody else
3) constructor is not called upon creation
I don't think the word "inout" expresses these concepts. It expresses
feature 1) partially, and the other two: not really!
So I propose again to use the "ref" instead of "inout"

In D you can not have one of these features withouth the other two. In C++
you can have 2) and 3) withouth having 1), by using const reference.

I would be happy with:
void foo(const ref a)
{
...
}

Yours,
Sandor
Nov 05 2002
parent reply Farmer <itsFarmer. freenet.de> writes:
Hi,

well, I feel that I can't really provide definite answers, because Walter 
has not yet answered the big question:    

What is D meant to be ?


Is D practically C++ with garbage collector (though reference counting 
might be supported, too), DBC and better arrays ?
Is D, what C++ is to C ?
So the final result will be "C/C++/D" ?

Or is D the successor to C++, as defined by 'a general purpose language 
biased to system programming' ?

Or is D the successor to C++, as defined by 'a general purpose language, as 
defined by contemporary  perception' ?


If D is not supposed to become "C/C++/D", where should it fit 
according to this oversimplyfied schema ?:

complexity                           easy to use
completeness                         easy to learn 
performance                          easy to maintain
realtime                             simplicity
open standard                        rapid development
                                     object oriented
                                     controlled by big company
                  bugfreeness ?
                  fun ?


<------------------------------------------------>

Does anybody know where to put in Eiffel ? ;-)




----
Sandor, I don't reply to all your comments, because I think that I 
basically agree with them, cannot add important facts to them and I don't 
see that they could object to the new in/out/inout semantics.
I might have missed an important issue: Please ask if you think an issue 
needs discussion.




 This decalaration is ugly:
 void foo(const inout a)
 {
 ...
 }
 But it is ugly not because the parameter list is long. The problem
 seems to be that how can an "inout" parameter be const.
 The solution is different terminonlogy. The "inout" keyword was used
 here to force passing by reference, but you would not like to use this
 reference to change the original value. References are used not only
 to change the original value. They are also usefull if you would
 always like to see the current value of the reffered variable, not
 some old value which it had at the time of copying. References has
 three semantical features: 1) you can change the original value in
 real-time, and 2) you can see the actual value if it was changed by
 somebody else 3) constructor is not called upon creation
 I don't think the word "inout" expresses these concepts. It expresses
 feature 1) partially, and the other two: not really!
 So I propose again to use the "ref" instead of "inout"


"inout" currently is a plain lie to me, "ref" would describe better whats 




...References has
 three semantical features: 1) you can change the original value in
 real-time, and 2) you can see the actual value if it was changed by
 somebody else 3) constructor is not called upon creation


I was not talking about references in general; my proposal is for an easier 
way to interface with functions.
Are you think of sth. like this ?

void main()
{
   structType v;
   ref structType r=v;          // no copy is made here
}
I don't think that is needed, because you can use pointers for that.





 
 In D you can not have one of these features withouth the other two. In
 C++ you can have 2) and 3) withouth having 1), by using const
 reference. 
 
 I would be happy with:
 void foo(const ref a)
 {
 ...
 }
 


I would be happy, if you had to write 
void(in const a*)

If you need some low level semantic, then pointers would fit. Unfortunately 
there is no const for pointers in D (yet!). But that could be solved 
easily.


 The solution is different terminonlogy.


I would just use the preprocessor of my brain:
#define ref inout
Now, it's easy to understand "C/C++/D".
Walter, doesn't have to change two lines of the spec and one in his 
compiler ;-) 


I consider the following odd:

C++: void foo(structType v)    	   // there is no real need for this one
same as
D: void foo(in structType v)              

C++
void foo(const structType& v)
simliar
D: void foo(inout structType v)              
or maybe
D: void foo(ref structType v)              

Why support a superfluous feature in a new language ?


another issue is

void foo(in fixedArrayType v);      // by reference, no copy is made
but
functionbody()
{
   char[5] a1,a2;                  
   a1[]=a2[];                  // assignment results in a copy 
}

Looks like D immitates C-style arrays.




 The C++ specification includes a statement similar to (excuse me, I
 don't have the specs with me now):
 "The compiler implementation is free to be different from this specs,
 if it can be proven that no user will ever notice the difference."


Interesting, now I understand why C++-compilers don't optimise all my C++ 
smart-pointers, because if they did, I would *notice* that my programs 
would be faster and would have a smaller code size. 



 A problem may arise if you try to call a function from a different
 compilation module.
 What kind of function call should the compiler insert into the object
 file? How can you guarantee that all modules calling the function will
 use the same call method?
 This kind of optimization seems to be possible only at link time, but
 reqires compilation. This would intermix the clear sequential process
 of compilation which Walter is fond of.


Always use the byreference calling convention for structs, as it is always 
reasonably fast. A very good optimizer does intermodule optimizing (see 
Intel C/C++ compiler), anyway. Therefore it could choose the best 
calling convention.



 If you still want immutable "in" parameters for value types, then why
 are we arguing about how to specify/implement fast mutable "in"
 parameters? 


Just want to prove, that the calling convention
C: foo(structType v) 
is superfluous even if you consider performance. 




 I don't find the first version ugly. How else would you return a
 structure? Return a reference to a local structure variable?
 


C++:
I would not return a struct at all. You don't have to do this because it is 
(at least usually) more efficient to pass in a (non-const) struct to a 
function. No API I have ever seen returns structs. (the C++ standard lib 
isn't an API)

Sometimes you do returns structs/classes in C++ because 
a) it's more convenient
b) required for some classes: typically smart-pointers, iteraters, etc.
But since you have a GC in D. It is easier to return a reference to a
class object.




 Heres it is in D:

 Point move(Point a, int x, int y)
 {
    Point result = a;

    result.x += x;
    result.y += y;
    return result;
 }

 Same as in C++, does not look that bad at all.


 
 
 Not that bad because of what?


Because, it is very easy to see what's happening for the maintenance-
programmer. It also prevents a possible bug.





 
 

 or 'better' (at least slower, I assume)

 class Point
 {
 private:
    int x;
    int y;
 public:
    void move(int x, int y)
    {
      this.x=x;
      this.y=y;
    }
 }
 Looks really good if you like OO-programming.


 
 Yes it looks good, but does a different thing. To do the same as the
 examples above, it should rather be:


Right. It's more OO-style, it does a different thing. But I suppose you can 
use it to accomplish the same task.


 
 Point move(int xd, int yd)
 {
    Point p = new Point(this);
    p.x += xd;
    p.y += yd;
    return p;
 }
 
 Now does it look good?


The function body constantly produces garbage, the user of the function 
cannot prevent this. If it's done in the OO-way, users may be able to reuse 
already created object-instances of the Point-class.
 





 In C++ const can only be useful, if the framework creator, (or library
 programmer), designed his system with the "const" concept in mind. For
 example standard Windows API functions don't specify const for the
 parameters they don't wan't to change. This makes using const with
 Windows API almost impossible. For example, the first parameter of the
 CreateFile function has the type of "char *", and not "const char *". 
 Therefore CreateFile does not sign a contract that it will not change
 the first parameter. CreateFile can change it if it likes to. So you
 should not pass a string literal as a filename! Now that is
 *inconvinient*, at least.


No. Here is the declaration from winbase.h:

typedef const CHAR* LPCSTR 
WINBASEAPI
HANDLE
WINAPI
CreateFileA(
    LPCSTR lpFileName,
    DWORD dwDesiredAccess,
    DWORD dwShareMode,
    LPSECURITY_ATTRIBUTES lpSecurityAttributes,
    DWORD dwCreationDisposition,
    DWORD dwFlagsAndAttributes,
    HANDLE hTemplateFile
    );




 But if you are creating the framework, const
 can be used as a contract. The compiler could and should check that
 the function don't violate the contract by changing the refered value.
 This can help bug-shooting at compile time. About half of library
 functions can and therefore should sign the contract to leave some
 parameters unmodified.  The compiler can help you find the places when
 the functions violate the contract, most of which will surely be bugs.


I also think, that for reference types a const modifier could be useful. My 
proposal does not interfere with const in anyway.

For value types const is not really needed (they could be allowed for 
language completeness):

C++:
void foo()
{
   int n1;
   const int n2;
   n1=n2;    	    	// can assign  non-const type to const type

   structType s1;
   const structType s2;
   s1=s2;	    	// can assign  non-const type to const type

   // C++ mixed with D reference type
   // -> won't compile with an ansi C++-compiler
   classType c1;
   const classType c2;

   c2=c1;    	    	// cannot assign non-const type to const type
    	    	    	    	// -> const types is really different from non-const
}

But currently D would require:
foo(inout const structType)          
or
foo(ref const structType)          

StructType is a value type, in my perception const has no meaning to value 
types. Thus current parameter passing semantics look strange for me.





From the user and the conceptual point of view, both of your examples use
pass by value, and I agree that the compiler should be free to choose from
these two, and several other implementations of pass by value. I don't 
think
you have invented any new semantics. These are just different compiler
implementations for the same semantic rule.


Passing of structs and fixed sized arrays have another behaviour than that 
mentioned in the D-spec (Ok. I don't see the behaviour really mentioned in 
the spec). It's a new concept, which is different from the C++-way.
Though, the compiler-implementation will be very similar.


Have a nice D.

'Farmer'
Nov 05 2002
parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
Warning. Quite a long letter to go.

"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns92BDEFCAD76FEitsFarmer 63.105.9.61...

 Hi,

 well, I feel that I can't really provide definite answers, because Walter
 has not yet answered the big question:

 What is D meant to be ?


As we was already told by Walter:
"What C++ should have been", and
"Successor to C"


 If D is not supposed to become "C/C++/D", where should it fit
 according to this oversimplyfied schema ?:

 complexity                           easy to use
 completeness                         easy to learn
 performance                          easy to maintain
 realtime                             simplicity
 open standard                        rapid development
                                      object oriented
                                      controlled by big company
                   bugfreeness ?
                   fun ?


 <------------------------------------------------>


Afaik, it aims to be the best of both worlds. With todays computing power
and experience, compilers could be able to compile a more intuitive language
effectively. It seems that you can almost get the fast developement time of
Java, together with the fast execution time of C/ASM.



...References has
 three semantical features: 1) you can change the original value in
 real-time, and 2) you can see the actual value if it was changed by
 somebody else 3) constructor is not called upon creation


 I was not talking about references in general; my proposal is for an


easier

 way to interface with functions.
 Are you think of sth. like this ?

 void main()
 {
    structType v;
    ref structType r=v;          // no copy is made here
 }
 I don't think that is needed, because you can use pointers for that.


That kind of usage of references is connected with parameter passing. It
wouldn't be clever to create a reference to a local variable in the same
function. But:

class Updater
{
  const ref int source;
  ref int target;
  int mul;
  Updater(const ref int source_i, ref int target_i, mul_i)
  {
    source = source_i;   // line 8
    target = target_i;
    mul = mul_i;
  }
  doUpdate()
  {
     target = source * mul;
  }
}

Apart from const, you can do something similar with pointers.


 In D you can not have one of these features withouth the other two. In
 C++ you can have 2) and 3) withouth having 1), by using const
 reference.

 I would be happy with:
 void foo(const ref a)
 {
 ...
 }


 I would be happy, if you had to write
 void(in const a*)

 If you need some low level semantic, then pointers would fit.


Unfortunately

 there is no const for pointers in D (yet!). But that could be solved
 easily.


Yes. But there is a widespread myth: "Pointers are evil, and with D you only
need them to interface to C".
If I remember right, pointers may interfere with garbage collection.


 The solution is different terminonlogy.


 I would just use the preprocessor of my brain:
 #define ref inout
 Now, it's easy to understand "C/C++/D".
 Walter, doesn't have to change two lines of the spec and one in his
 compiler ;-)


Any serious programmer is capable of such "brain preprocessing", and it is
inevitable to rely on it. But I think we should minimize the need for it, by
using the most intuitive keywords, and structure.


 I consider the following odd:

 C++: void foo(structType v)       // there is no real need for this one
 same as
 D: void foo(in structType v)

 C++
 void foo(const structType& v)
 simliar
 D: void foo(inout structType v)
 or maybe
 D: void foo(ref structType v)

 Why support a superfluous feature in a new language ?


In C++, it was not superfluous. In the firts case the constructor is run, so
the result may be different. In D, no consturtor is run, but taking into
account the "raii" feature of D, the result may also be different.


 The C++ specification includes a statement similar to (excuse me, I
 don't have the specs with me now):
 "The compiler implementation is free to be different from this specs,
 if it can be proven that no user will ever notice the difference."


 Interesting, now I understand why C++-compilers don't optimise all my C++
 smart-pointers, because if they did, I would *notice* that my programs
 would be faster and would have a smaller code size.


:)


 A problem may arise if you try to call a function from a different
 compilation module.
 What kind of function call should the compiler insert into the object
 file? How can you guarantee that all modules calling the function will
 use the same call method?
 This kind of optimization seems to be possible only at link time, but
 reqires compilation. This would intermix the clear sequential process
 of compilation which Walter is fond of.


 Always use the byreference calling convention for structs, as it is always
 reasonably fast. A very good optimizer does intermodule optimizing (see
 Intel C/C++ compiler), anyway. Therefore it could choose the best
 calling convention.


I see.



 If you still want immutable "in" parameters for value types, then why
 are we arguing about how to specify/implement fast mutable "in"
 parameters?


 Just want to prove, that the calling convention
 C: foo(structType v)
 is superfluous even if you consider performance.


You proved that there are no actual performace difference, when using small
structures. But there are other differences. Such as when using references,
changes to the refered data is immediately visible to you, whereas when
using value copying, the copy does not change if the original value is
changed. In some cases the first is desirable in some cases the second.


 I don't find the first version ugly. How else would you return a
 structure? Return a reference to a local structure variable?


 C++:
 I would not return a struct at all. You don't have to do this because it


is

 (at least usually) more efficient to pass in a (non-const) struct to a
 function. No API I have ever seen returns structs. (the C++ standard lib
 isn't an API)


Yeah, an API has to be effecient. But in the user code, at certain places,
it may be simpler to get back a value from a function, rather that passing a
reference to an object you created beforehand. Just like with an int or
double type.  However, if the compiler likes to, it can restructure the code
to avoid the actual copy.


 In C++ const can only be useful, if the framework creator, (or library
 programmer), designed his system with the "const" concept in mind. For
 example standard Windows API functions don't specify const for the
 parameters they don't wan't to change. This makes using const with
 Windows API almost impossible. For example, the first parameter of the
 CreateFile function has the type of "char *", and not "const char *".
 Therefore CreateFile does not sign a contract that it will not change
 the first parameter. CreateFile can change it if it likes to. So you
 should not pass a string literal as a filename! Now that is
 *inconvinient*, at least.


 No. Here is the declaration from winbase.h:

 typedef const CHAR* LPCSTR
 WINBASEAPI
 HANDLE
 WINAPI
 CreateFileA(
     LPCSTR lpFileName,
     DWORD dwDesiredAccess,
     DWORD dwShareMode,
     LPSECURITY_ATTRIBUTES lpSecurityAttributes,
     DWORD dwCreationDisposition,
     DWORD dwFlagsAndAttributes,
     HANDLE hTemplateFile
     );


Sorry, I was wrong with CreateFile. Nevertheless const is only a problem if
it is not used. Nobody says: "lets change CreateFile declaration so that the
type of first parameter is non-const"!


 But if you are creating the framework, const
 can be used as a contract. The compiler could and should check that
 the function don't violate the contract by changing the refered value.
 This can help bug-shooting at compile time. About half of library
 functions can and therefore should sign the contract to leave some
 parameters unmodified.  The compiler can help you find the places when
 the functions violate the contract, most of which will surely be bugs.


 I also think, that for reference types a const modifier could be useful.


My

 proposal does not interfere with const in anyway.

 For value types const is not really needed (they could be allowed for
 language completeness):

 C++:
 void foo()
 {
    int n1;
    const int n2;
    n1=n2;        // can assign  non-const type to const type

    structType s1;
    const structType s2;
    s1=s2;     // can assign  non-const type to const type


afaik, there is no casting here


    // C++ mixed with D reference type
    // -> won't compile with an ansi C++-compiler
    classType c1;
    const classType c2;

    c2=c1;        // cannot assign non-const type to const type
                 // -> const types is really different from non-const
 }

 But currently D would require:
 foo(inout const structType)
 or
 foo(ref const structType)

 StructType is a value type, in my perception const has no meaning to value
 types. Thus current parameter passing semantics look strange for me.
Nov 06 2002
parent Farmer <itsFarmer. freenet.de> writes:
"Sandor Hojtsy" <hojtsy index.hu> wrote in
news:aqb74i$1p86$1 digitaldaemon.com: 


 Warning. Quite a long letter to go.


???
It actually is the shortest message in this thread, except for Antti's 
post.



 As we was already told by Walter:
 "What C++ should have been", and
 "Successor to C"


I see. In my perception it is already the successor to "C/C++" (in a  
technical sense). 

My guess: It will inevitably become known as "C/C++/D".
 

 If D is not supposed to become "C/C++/D", where should it fit
 according to this oversimplyfied schema ?:

 complexity                           easy to use
 completeness                         easy to learn
 performance                          easy to maintain
 realtime                             simplicity
 open standard                        rapid development
                                      object oriented
                                      controlled by big company
                   bugfreeness ?
                   fun ?


 <------------------------------------------------>


 
 Afaik, it aims to be the best of both worlds. With todays computing
 power and experience, compilers could be able to compile a more
 intuitive language effectively. It seems that you can almost get the
 fast developement time of Java, together with the fast execution time
 of C/ASM. 


The phrase "what you don't need/use, you won't have to pay for" is true for 
performance considerations. But when it comes to simplicity, you can only  
compromise. 
If you want/need everything C provides, you'll basically get everything C 
has, including its drawbacks. Of course, everything made up by man's 
thoughts can be improved a bit. 

 

 That kind of usage of references is connected with parameter passing.
 It wouldn't be clever to create a reference to a local variable in the
 same function. But:


I wanted to separate parameter passing from reference:. I'm in a quest for 
a language suitable for true general application programming. Java was not 

implement it won't become very portable. Not to mention that for political 
reasons, few companys will try to port it, anyway.

I need clean, easy maintainable code for maxium business profit (of my 
bosses). But never mind, I can gain as much money by using unsuitable 
languages as I can gain with great languages. And the same rule applys to 
my bosses.

The code below is a real maintanance nightmare for me. I had never to write 
anything like that. Obviously, you are doing same very different kind of 
programming-tasks than I do. Consequently, I cannot provide anything 
helpful to the D language. My thoughts are different because my needs are 
different.


How can you be sure that, the passed reference is always valid ? It might 
be allocated on the stack.
If I have to do such quick and dirty stuff, I would use pointers, so 
everybody sees what I'm doing (doing some dirty stuff, which requires some 
specific unusual semantics).



 Yes. But there is a widespread myth: "Pointers are evil, and with D
 you only need them to interface to C".


They are not evil. They are powerful, rather bug-prone, and hard to 
understand. Sometimes they hinder good optimizations by the compiler. 
Still, I would only need/use them to interface with C-api. 


 If I remember right, pointers may interfere with garbage collection.


My guess is that they don't interfere, as long as you doing things the way 
as C++-reference types work.



 Any serious programmer is capable of such "brain preprocessing", and
 it is inevitable to rely on it. But I think we should minimize the
 need for it, by using the most intuitive keywords, and structure.


I fully agree. Keep looking out for some more misleading keywords in 
current/future D versions. 




 I consider the following odd:

 C++: void foo(structType v)       // there is no real need for this
 one same as
 D: void foo(in structType v)

 C++
 void foo(const structType& v)
 simliar
 D: void foo(inout structType v)
 or maybe
 D: void foo(ref structType v)

 Why support a superfluous feature in a new language ?


 
 In C++, it was not superfluous. In the firts case the constructor is
 run, so the result may be different. In D, no consturtor is run, but
 taking into account the "raii" feature of D, the result may also be
 different. 


[Since I know by now that D will become "C/C++/D", it no longer strikes my 
that everybody in the D-newsgroup (including myself)  talks more about C++ 
than about D. It's likely to become D's doom.]

I don't see how raii interfered with my proposal, since raii applys only 
for classes. The semantic for classes was not affected by my proposal.



 If you still want immutable "in" parameters for value types, then
 why are we arguing about how to specify/implement fast mutable "in"
 parameters?


 Just want to prove, that the calling convention
 C: foo(structType v)
 is superfluous even if you consider performance.


 
 You proved that there are no actual performace difference, when using
 small structures. But there are other differences. Such as when using
 references, changes to the refered data is immediately visible to you,
 whereas when using value copying, the copy does not change if the
 original value is changed. In some cases the first is desirable in
 some cases the second. 


[I already mentioned it in this post] I don't have the need for such low-
level semantics in general, whenever I have I use pointers. But honestly, I 
simply have the wrong background for such thoughts. 




 Yeah, an API has to be effecient. But in the user code, at certain
 places, it may be simpler to get back a value from a function, rather
 that passing a reference to an object you created beforehand. Just
 like with an int or double type.  However, if the compiler likes to,
 it can restructure the code to avoid the actual copy.


Right. Though, I swear that I am NEVER going to return a struct-type in D ( 
if I ever got an employer that would let me write in D). Though, I did not 
ban it in my proposal for language completeness considerations.



 For value types const is not really needed (they could be allowed for
 language completeness):

 C++:
 void foo()
 {
    int n1;
    const int n2;
    n1=n2;        // can assign  non-const type to const type

    structType s1;
    const structType s2;
    s1=s2;     // can assign  non-const type to const type





 

    // C++ mixed with D reference type
    // -> won't compile with an ansi C++-compiler
    classType c1;
    const classType c2;

    c2=c1;        // cannot assign non-const type to const type
                 // -> const types is really different from non-const
 }

 But currently D would require:
 foo(inout const structType)
 or
 foo(ref const structType)

 StructType is a value type, in my perception const has no meaning to
 value types. Thus current parameter passing semantics look strange
 for me. 





 
 afaik, there is no casting here


You are right. My example is wrong. 
Every variable must be toggled to become a sensible example. Then it reads 
"cannot assign const *reference* type to non-const *reference* type". [Note 
that this restriction does not apply to value types.]



Have a nice "C/C++/D".


'Farmer'
Nov 06 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns92B816E513F51itsFarmer 63.105.9.61...

 Questions about "C++ const" to Walter:
 -------------------------------------

 Though I did not find anything in the D spec (this night) regarding "C++
 const" , I do remember that you (Walter) said, that the "const" concept of
 C++ does not really pay off - so you do not want to provide a similar
 concept for D. My problem is, that I did not get the point what the bad
 points of "C++ const" are EXACTLY.


1) It does not aid optimization. For example, if you have the following:

    int *p;
    const int *q = p;

    a = *q;
    *p = b;
    c = *q;

Oh well, *q has changed, so the compiler can make no use of the programmer
having called it const. While this example is trivial, I've run into enough
real world cases (by turning that optimization on) that subtly break due to
dependencies like this that a real world compiler cannot do those
optimizations. It does no good to say such programs are broken - it can be a
daunting task to figure out why a complex program broke with such
optimizations turned on, and nobody will make the effort when the program
"works" with Brand X compiler.

2) Many people strongly disagree with me on this point: in many years and
lots of code using 'const', it simply never has exposed a bug in my
experience. I just stopped using it and haven't missed it.

3) You can legally cast away const-ness. Hence, as a contract, it is
unreliable.

4) The 'mutable' keyword is another hole in it.

5) Const as a type modifier permeates the type system, and has effects
spilling all over places it has no business doing so. For example, it
affects the partial specialization rules of templates, not in any clarifying
way, but just adding more layers of complexity and special case rules.

6) Const-correct code seems to be simply loaded with const const here a
const there a const const that I find distracting and annoying. (Yes, that's
a personal opinion!)

I'm not saying const has zero benefit - it does have some benefit. But its
costs exceed its benefits.


 Here are my assumptions about bad points of the "C++ const" concept that
 you might have.

 1. Const does not pay off, because to few C++ programmers actually use it.
 You can not use const objects with frameworks, because they have to many
 non-const functions.

 2. Const does not pay off, because when programming with large
 frameworks/codebase, too many functions are inherently non-const: A
 reference to a const object is almost useless, because at some point you
 simply must call one of these non-const functions. So, you end up using
 const casts all the time. (alternatively you can store two versions of
 every reference)

 3. It is too disheartening that const inherently is not usefull for good
 optimizations.

 3. It is too disheartening that const cannot be used for optimizations,
 because the C++ semantic of const/the common programming practice with
 const in C++, prevent any optimizations.

 4. Const clutteres the declarations of functions and reference types too
 much.

 5. Const complicates the rules for function overloading, function
 overriding, class inheritence and interface inheritance, etc. too much.

 6. It is too difficult to make a compiler that checks for constness.
Nov 30 2002
next sibling parent reply "Robert W. Cunningham" <FlyPG users.sourceforge.net> writes:
A systems programming language (SPL) requires two fundamental features
of its type system in order to meet any minimal definition of being an
SPL:  'const' and 'volatile' (or equivalent).  Even Ada has them, in
very constrained but still VERY useful forms.

"Const" (and 'volatile', while we're at it) does not have to have
universal applicability in order to be valuable and useful.  "Sloppy"
use of const should not be encouraged, and shouldn't be tolerated when
detected.  In my C code, I find using "gcc -Wall" helps quite a bit.


Walter wrote:

 ...
 
 1) It does not aid optimization. For example, if you have the following:
 
     int *p;
     const int *q = p;
 
     a = *q;
     *p = b;
     c = *q;
 
 Oh well, *q has changed, so the compiler can make no use of the programmer
 having called it const. While this example is trivial, I've run into enough
 real world cases (by turning that optimization on) that subtly break due to
 dependencies like this that a real world compiler cannot do those
 optimizations. It does no good to say such programs are broken - it can be a
 daunting task to figure out why a complex program broke with such
 optimizations turned on, and nobody will make the effort when the program
 "works" with Brand X compiler.


This is caught by "gcc -Wall" and flagged with a warning.  I'd make it
an error in D.  Forbid it!


 2) Many people strongly disagree with me on this point: in many years and
 lots of code using 'const', it simply never has exposed a bug in my
 experience. I just stopped using it and haven't missed it.


I use const LOTS simply to get rid of #defines:

   const char LF = '\n';	// Enum works too...

Or for strings I use often:

   const char * const errMsgHdr = "ERROR:  ";	// Double const is needed!

More realistically, in embedded code:

   // A pointer to a volatile 8-bit hardware register:
   const unsigned char * volatile pHardware = (unsigned char
*)0xFEEDFACE;

Without const and volatile both, the above hardware register would
likely become 'static', with the programmer (NOT the compiler) being
tasked with "remembering" not to step on them!  This is something
compilers should do for us.

Of course, a C or ASM library could be written to take care of the need
for volatile in D.  But then again, I can do that for ANY non-SPL. 
That's how OSes written in Smalltalk and Lisp get the low-level hardware
stuff done.  Why?  Because Smalltalk and Lisp are NOT Systems
Programming Languages!

But not even an external library can provide const-like properties.  I'd
probably need to use assembler to force a variable to be allocated in
the segment containing the object code, and pray that D will still be
able to find and use it.  That may work for a device driver, but it
requires a non-D OS to provide the segment protection needed via MMU
programming.

Too many work-arounds make a language non-SPL.



 
 3) You can legally cast away const-ness. Hence, as a contract, it is
 unreliable.


Let's change that in D!  Make it as difficult as possible to cast away
constness.  You can always emit a Big Fat Greek Warning whenever const
is used:

  "WARNING: Const Considered Harmful!"



 
 4) The 'mutable' keyword is another hole in it.


I don't use 'mutable'...  But can't this be handled with another noisy
warning?


 
 5) Const as a type modifier permeates the type system, and has effects
 spilling all over places it has no business doing so. For example, it
 affects the partial specialization rules of templates, not in any clarifying
 way, but just adding more layers of complexity and special case rules.
 


Disallow its use in such circumstances!  Yes, this will require some
up-front checking for such use, but no back-end support at all.

Permit const to apply only to fundamental types, and pointers to such
types (that's all I really need).  No const structs or anything else.  I
doubt there is any great need for structs to have const members.

I'm willing to violate OO doctrine and software engineering practices
WHEN JUSTIFIED to access whatever minimalist const or volatile syntax is
implemented in D.  Perhaps I'll need to make all my consts and volatiles
global, and put them in their own file.  Ugly, but at least I'll have
the feature present in some form to use when I need it.

If the type system is so fragile and difficult, then move const and
volatile as far to the edge of it as possible.  I'll gladly accept
that.  But don't just leave them out!



 6) Const-correct code seems to be simply loaded with const const here a
 const there a const const that I find distracting and annoying. (Yes, that's
 a personal opinion!)


Yes!  It *should* be ugly!  That will discourage its use.  But when it
is needed, it should NOT always be impossible.  Merely difficult (and
ugly) will suffice.

D has already made this trade-off at least once, and it is a good one to
make, especially for "risky" features.



 
 I'm not saying const has zero benefit - it does have some benefit. But its
 costs exceed its benefits.


Contain const's costs by constraining const's contexts.  Don't kill the
entire concept!  Both const and volatile are VITAL to any Systems
Programming language that is intended to be used to do any systems
programming (as opposed to applications programming).


<exapseration=ON>

Has anyone tried to write a device driver in D?  How about a small OS
(or a port of uCOS) that boots itself?  Those are the kids of things
Systems Programming Languages are created for.  I don't think they can
be done in D without lots of work-arounds in assembler that C doesn't
need:  D doesn't play nice with hardware, especially when the processor
has a cache.  Ergo, (IMHO) D is not (yet) a systems programming
language.

These fundamental type system features (const and volatile) must be part
of D (in some form), or else D's moniker of being a "Systems Programming
Language" is false by definition.  It should be replaced with something
more appropriate, such as "Yet Another Non-Systems Programming Language,
But One That's Easier For C Programmers To Use."

Walter, all your points AGAINST const are valid!  Just because you know
of many misuses for and difficulties with 'const' doesn't mean there
still aren't many VALID needs and uses for const and volatile.  Just
because you haven't encountered them and can't envision them does not
mean they don't exist.  It only means I suck at explaining them.  I wish
I could craft a better argument, or provide the needed insight and
education.  Despite several tries, I have failed miserably to convince
you.

As I've said repeatedly, I'm no language guru.  But I know what I need
my tools to do, and D doesn't do what's needed for system programming. 
I already use about a dozen languages (some far better than others), and
I have all the non-system programming languages I need.  I don't need
another one, even if it is as good as D.

I'm running out of reasons to keep arguing for adding 'const' and
'volatile'
to D.  The door appears to be firmly shut, and there is no point in
banging my head against it or shouting at it any longer.

D is **NOT** a Systems Programming Language.  Please call it something
else so others like myself (who program embedded systems, real-time
systems, device drivers and operating systems for a living) won't be
encouraged to waste their time and breath on it.

Or you can simply TRUST ME that some minimal form of 'const' and
'volatile' are mandatory for systems programming, and add them to the D
language specification.

</exasperation>


-BobC
Dec 02 2002
next sibling parent Evan McClanahan <evan dontSPAMaltarinteractive.com> writes:
Robert W. Cunningham wrote:

 A systems programming language (SPL) requires two fundamental features
 of its type system in order to meet any minimal definition of being an
 SPL:  'const' and 'volatile' (or equivalent).  Even Ada has them, in
 very constrained but still VERY useful forms.
 
 "Const" (and 'volatile', while we're at it) does not have to have
 universal applicability in order to be valuable and useful.  "Sloppy"
 use of const should not be encouraged, and shouldn't be tolerated when
 detected.  In my C code, I find using "gcc -Wall" helps quite a bit.


First off, I'm in the C++ const is bad camp.  It has too many variant 
meanings, and as Walter has said, it doesn't really prevent all that 
many bugs, IMO.  const, as it stands now in D, is fine with me.  It 
means constant, and cannot be changed at runtime.  It's a binding 
contract, which is what const should be.  The only think that I would 
add, if it's possible, is to add const type functions, although with 
another keyword.  Basically, it would be another contract, with no 
passed in variables, pointers, or references being changeable in the 
body of that particular function.  Anything not in the local scope being 
assigned a value of any kind would be an error.  I don't know if this is 
possible, from a compiler writer's standpoint, but of all the variant 
meanings of const, this is the only one that I would support adding to 
D.  Like I said, I don't know about the keyword (other than it needs to 
be called something other than const) but I'm sure that we can come up 
with something that fits the semantics well.

Evan
Dec 03 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <FlyPG users.sourceforge.net> wrote in message
news:3DEC11FC.DB684E1C users.sourceforge.net...

 Has anyone tried to write a device driver in D?  How about a small OS
 (or a port of uCOS) that boots itself?  Those are the kids of things
 Systems Programming Languages are created for.  I don't think they can
 be done in D without lots of work-arounds in assembler that C doesn't
 need:  D doesn't play nice with hardware, especially when the processor
 has a cache.  Ergo, (IMHO) D is not (yet) a systems programming
 language.


I am intimately familiar with how C compilers generate code, with and
without const and volatile. There just isn't much to be gained with it, and
a lot of trouble is caused by it. D, however, does support the const as a
storage class, as in:

    const foo = 3;

D also supports the volatile statement, which prevents caching of values
across the statement boundaries. The combination of this, the const storage
class, and the ability to access arbitrary addresses with pointers, I think
fills the bill.

D also has, unlike C or C++, a defined interface to assembler. Take a look
at the linux kernel source, it is full of random bits of assembler. That
doesn't mean that C isn't a systems programming language. What it does mean
is that the awful gnuc inline assembler leaves a lot of room for
improvement, which D does.



 Walter, all your points AGAINST const are valid!  Just because you know
 of many misuses for and difficulties with 'const' doesn't mean there
 still aren't many VALID needs and uses for const and volatile.  Just
 because you haven't encountered them and can't envision them does not
 mean they don't exist.  It only means I suck at explaining them.  I wish
 I could craft a better argument, or provide the needed insight and
 education.  Despite several tries, I have failed miserably to convince
 you.


I do respect your opinion on this, and I have been equally hard at work
trying to convince you otherwise!


 Or you can simply TRUST ME that some minimal form of 'const' and
 'volatile' are mandatory for systems programming, and add them to the D
 language specification.


They are there in the (minimal) form mentioned earlier. And yes, I have
written device drivers in both C and assembler.
Dec 14 2002
prev sibling parent reply Russell Lewis <spamhole-2001-07-16 deming-os.org> writes:
Robert W. Cunningham wrote:

 A systems programming language (SPL) requires two fundamental features
 of its type system in order to meet any minimal definition of being an
 SPL:  'const' and 'volatile' (or equivalent).  Even Ada has them, in
 very constrained but still VERY useful forms.


Assembly language doesn't have 'const' or anything equivalent.  So how 
can you say it is required or a system programming language?

As for volatile, that only impacts optimization techniques.  Since 
assembly language programs are normally not optimized by the assembler, 
volatile is not needed.  Likewise, you can turn off all optimizations in 
  a compiler and thus volatile won't be necessary there, either.

Thus, neither is actually necessary.  IMHO, Walter's design, while not 
perfect, is an incremental advance over C/C++.  It allows us to use 
volatile statements to read & write things, but gives us more 
optimization than C allowed.
Dec 16 2002
parent reply Pedro Alves <Pedro_member pathlink.com> writes:
Russell Lewis <spamhole-2001-07-16 deming-os.org> Wrote:

As for volatile, that only impacts optimization techniques.


Well, in C, volatile is usefull when I have a variable that is a representation
of an I/O port that is connected to some hardware you're monitoring. For
instance, say your program is deciding something based on the state of a sensor.
Because you never know when the state of the port will change, you'll have to
use volatile to force the program to really check the port, otherwise you're
(maybe/probable) hitting an old cached value, and get wrong results.
How does D solve that?
Mar 09 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Pedro Alves" <Pedro_member pathlink.com> wrote in message
news:b4f1eo$1dd9$1 digitaldaemon.com...

 Russell Lewis <spamhole-2001-07-16 deming-os.org> Wrote:

As for volatile, that only impacts optimization techniques.


 Well, in C, volatile is usefull when I have a variable that is a


representation

 of an I/O port that is connected to some hardware you're monitoring. For
 instance, say your program is deciding something based on the state of a


sensor.

 Because you never know when the state of the port will change, you'll have


to

 use volatile to force the program to really check the port, otherwise


you're

 (maybe/probable) hitting an old cached value, and get wrong results.
 How does D solve that?


 volatile !

http://www.digitalmars.com/d/statement.html#volatile
Mar 09 2003
prev sibling parent reply Farmer <itsFarmer. freenet.de> writes:
"Walter" <walter digitalmars.com> wrote in
news:asccu1$h8l$1 digitaldaemon.com: 


 5) Const as a type modifier permeates the type system, and has effects
 spilling all over places it has no business doing so. For example, it
 affects the partial specialization rules of templates, not in any
 clarifying way, but just adding more layers of complexity and special
 case rules. 



I have a simple question about current C++/D compiler implementations, just 
to assure that I'm on the right way:

Would it make the D compiler implementation easier if D treated "const 
someRefType" as the imaginary base-type of the type "someRefTyp" ?

All rules for overloading, type compatibilty, partial template 
specialization, etc. that are used for inherited types are simply applied 
to const.

Sure, the type hierarchy of const is a bit special:

example:

class Base
{}

class Child : Base
{}

now the imaginary inheritance tree would be:

a)"const Child"  inherits  "const Base".
but 
b)Child  inherits  "const Child"  inherits  Base  inherits  "const Base".



I suppose that you can deduce most rules of C++ regarding const with this 
simple notion.

One exception I know of, are the partial specialization rules of C++ 
templates. But these rules look counter-intuitive and are often useless. 
The rules deduced from my notion of const do not look worse than those of 
C++ to me. Maybe they are even better. 

Could anyone provide an example that proves that my simple notion of const 
cannot fit the bill ?


Farmer
Jan 13 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Farmer" <itsFarmer. freenet.de> escreveu na mensagem
news:Xns9303EEFE9D5FitsFarmer 63.105.9.61...

 "Walter" <walter digitalmars.com> wrote in
 news:asccu1$h8l$1 digitaldaemon.com:


 5) Const as a type modifier permeates the type system, and has effects
 spilling all over places it has no business doing so. For example, it
 affects the partial specialization rules of templates, not in any
 clarifying way, but just adding more layers of complexity and special
 case rules.



 I have a simple question about current C++/D compiler implementations,


just

 to assure that I'm on the right way:

 Would it make the D compiler implementation easier if D treated "const
 someRefType" as the imaginary base-type of the type "someRefTyp" ?

 All rules for overloading, type compatibilty, partial template
 specialization, etc. that are used for inherited types are simply applied
 to const.

 Sure, the type hierarchy of const is a bit special:

 example:

 class Base
 {}

 class Child : Base
 {}

 now the imaginary inheritance tree would be:

 a)"const Child"  inherits  "const Base".
 but
 b)Child  inherits  "const Child"  inherits  Base  inherits  "const Base".



 I suppose that you can deduce most rules of C++ regarding const with this
 simple notion.

 One exception I know of, are the partial specialization rules of C++
 templates. But these rules look counter-intuitive and are often useless.
 The rules deduced from my notion of const do not look worse than those of
 C++ to me. Maybe they are even better.

 Could anyone provide an example that proves that my simple notion of const
 cannot fit the bill ?


 Farmer


Hi,

    This subject is one of those continuous discussions on Usenet.
comp.lang.eiffel has some posts talking about this, regarding CQS
(command/query separation) and lots of people talked about it. Here's my
thoughts about it.
    There are two views of what "const" means when applied to types:

(1) this is constant and will never change; or
(2) this is mutable but YOU can't change.

    Each gives a whole different world to the compiler and to the
programmer. Also there's const applied to functions, both with two different
views:

(A) this function is a pure function, you can use equational reasoning about
it; or
(B) this function won't change any of it's parameters (including implicit
this for methods), or that's what I want you to think.

    When you create a const ancestor type to any type, you want it to mean
both const for type (either 1 or 2) with interfaces defined for the type's
const functions (either A or B). These four possible combinations can give
us lots of headache. So let's think about them:

(1A) this means functional objects, that is objects with value semantics.
Structs aren't true value objects but C/C++ folk usually talk about them
being so. Anyway you could define:

class Color {
    const Color darker();
    const Color lighter();
    const int alpha();
    const int red();
    const int green();
    const int blue();
    const float hue();
    const float saturation();
    const float brightness();
    const char[] toString()
    void printOn(OutputStream out)
}

and a type const Color would be defined with all these methods in it. Note
that const in the methods applies to the method, not to the result type, so
char[] from toString() is mutable and Color from darker() and lighter() too,
not that it means something. But it gives you two functions that map const
Color domain to Color domain.


(1B) this is similar to 1A, but includes trick functions. In the same Color
class we could define this:

class Color {
// same as before
    const int cyan();
    const int magenta();
    const int yellow();
    const int black();
}

    The four new methods are const, but inside their definitions they break
the rules lazily caching the values so multiple uses won't result in
multiple computations. All cache mechanisms for pure-functions must "cast
away the constness".


(2A) Useful for restricting user's access to mutable methods of types.

class Car {
    const void lookAt();
    const void wash();
    void drive();
    void crash();
}

class SomeoneElse {
    void driveInto(Car target);
}
abstract class Driver {
    abstract (const Car) lendCarTo(const Driver any);
    abstract Car lendCarTo(const GoodDriver good);
}
class LameDriver : Driver {
}
class GoodDriver : Driver {
}

I think it's valid overloading. The GoodDriver class can access a more
complete version of Car, because it will never call the mutable method
crash(), but needs to use drive(). LameDriver's skills stop him from doing
anything besides lookAt() and wash(). But while LameDriver lookAt() theCar
SomeoneElse can driveInto(theCar) and crash it anyways, because they can
mutate it. It's the same problem with collections and immutable interfaces,
or using iterators while another thread changes the collection.


(2B) Similar to 2A, but in this case drive() could be also declared const
and secretly update the gas tank during all method calls.


    Each combination has it's strengths and weaknesses, now let's see how
could we implement this mess of semantics in D:

(1A) give a const modifier to classes and functions. It's similar to Sather
immutable objects. It will help people define better semantics for their
types (a Date class could be const, like it should be, not like some other
OO languages do ;-) ).

(1B) It's 1A plus a cast to allow secret mutations. Walter will love it ;-)

(2A) give more things to the compiler play with. It's also a fun thing to
toy with: slice operations give const type or type? Current D's array
semantics (very pragmatic) use COA (like COW but appending instead of
writing), so "type [index] = value" should be a operation of const type, but
"type ~= value" should be a operation of type.

(2B) more fun than 2B, after all you can always cast the constness away to
make things weirder.


    AFAICS this is that const means lots of things, and each of these things
is different from the others. We should think very carefully before changing
any type system semantics with such huge change. No imperative language
currently has this (and IIRC not hibrid language too).

    Best regards,
    Daniel Yokomiso.

P.S.: When I implement my pet language, Eon, I'll give it immutable types
and values, but it's goals and type system are different from D's. I'm
entering on the second year of study to create it's type system (hundreds of
papers read) and in the meantime I put and dropped immutable types several
times. If someone is interested I plan to provide both 1A and 2A, but
throught two different mechanisms.

"Chaos! Panic! Disaster! (My work here is done)."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.435 / Virus Database: 244 - Release Date: 30/12/2002
Jan 14 2003
parent Farmer <itsFarmer. freenet.de> writes:
Hi,

my question
"Could anyone provide an example that proves that my simple notion of
const cannot fit the bill ?"

should read: "Are all those complicated rules of C++ regarding "const", 
really necessary. Please show me examples, where my simple notion of const 
(mapping the const attribute to a class hierarchy), would not work in C++ 
or in D".
By "const", I primarily think of "const" applied to class methods in C++.


now my comments on your post:

I think the 2B meaning of constness is most useful for D programmers.


(2) this is mutable but YOU can't change.
(B) this function won't change any of it's parameters (including
 implicit this for methods), or that's what I want you to think.


Equational reasoning is not a concern for most D programmers. They usually 
think that functions do some work like  I/O operations.

The meaning

(1) this is constant and will never change; 


is too limiting for most cases. Of course there could be uses: e.g. 
java.lang.String 


 abstract class Driver {
     abstract (const Car) lendCarTo(const Driver any);
     abstract Car lendCarTo(const GoodDriver good);
 }


I guess, you wanted to write 
 abstract class Driver {
     abstract (const Car) lendCarTo(Driver any);
     abstract Car lendCarTo(GoodDriver good);
 }
since the state of both Driver and GoodDriver instance will change. (now 
they have access to a car)


 I think it's valid overloading. The GoodDriver class can access a more
 complete version of Car, because it will never call the mutable method
 crash(), but needs to use drive(). LameDriver's skills stop him from
 doing anything besides lookAt() and wash(). But while LameDriver
 lookAt() theCar SomeoneElse can driveInto(theCar) and crash it
 anyways, because they can mutate it. It's the same problem with
 collections and immutable interfaces, or using iterators while another
 thread changes the collection. 


Right. But that is exactly the meaning that should be expressed by 
constness: You prevented the LameDriver from crashing your car. But a 
tornado still can do that (You cannot prevent that in real life ->a 
compiler can't do either). You need to design an indestructable car to get 
an immutable Car class. 


 (2A) give more things to the compiler play with. It's also a fun thing
 to toy with: slice operations give const type or type? Current D's
 array semantics (very pragmatic) use COA (like COW but appending
 instead of writing), so "type [index] = value" should be a operation
 of const type, but "type ~= value" should be a operation of type.
 (2B) more fun than 2B, after all you can always cast the constness
 away to make things weirder.


My knowledge about pure functions are non existent, so I'm surely missed 
some fun.
Why should "type [index] = value" be an operation of const ?

According to my simple rules for const. You could only get a "const slice" 
from a "const slice". But from a "nonconst slice" you can get both version. 



     AFAICS this is that const means lots of things, and each of these
     things 
 is different from the others. We should think very carefully before
 changing any type system semantics with such huge change.


That's why I'm asking Walter whether it is possible to reduce the 
complexity of constness (for both compiler writers and programmers) in 
first placen, BEFORE I'm trying to work out a proposal to introduce const 
to D. And I think, it's likely to be impossible to introduce const to D's 
type system. The type system is already complex hardly any support for 
constness.



Well, I have some thoughts about const, too:

I feel that the following notions of constness could be useful to a 
programming language like D.

typical keywords:  meaning

1)const (D):  compile time constants; no memory is allocated for these 
constants.

has been initialized.
3)const (C++ in context of methods):  logical (not necessarily bitwise) 
constness of UDT's, meaning that the object state cannot be change using 
this variable identifier.
4)__romable, const (Ansi C99 ?):  variable can be stored in ROM-memory; its 
value will never change. [I don't need that, but maybe some embedded 
systems programmers will love it.]  
5)__callconst:  this attribute can only be applied to non-const arguments 
of functions. It should mean that the argument is not changed within the 
function. But the argument is usually stored in a global variable (or 
member variable ). This constness could be useful for container classes: 
E.g. a stack stores an non-const object with the push() method. This method 
does not change the object. Though, this method cannot take an const 
argument, because you want to get a non-const object back from the stack 
with the pop() method.

Unfortunately I, see no solution for a D-compiler to enforce this behaviour 
-> this keyword could only be syntax sugar for writting self-documenting 
code. Of course, one could hack the language to catch at least the most 
obvious violations of "__callconst". 

Do you know of any language, that can express constness as required for 
container classes ?


Farmer.
Jan 19 2003