www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const, in and final

reply Arcane Jill <Arcane_member pathlink.com> writes:
I have given a lot of thought to the whole "const" thing, and it seems to me
that there is a way around this that will keep everybody happy. (It was not I
who thought of this, by the way - I'm just clarifying).

Summary - the story so far:
Three uses of const have been identified in C++
(1) To declare a complile-time constant
(2) To declare an instance of something which needs to be stored in ROM
(3) As part of Design-By-Contract, to specify a contract that a function will
not modify something

The keyword "const" is implemented in D to allow use (1) only.

It has been suggested that the distinction between (1) and (2) could be decided
by the compiler. Alas, that may not be so. Given the declaration:

       const int FORTY_TWO = 42;

the expression (&FORTY_TWO) should be illegal in case (1), but legal in case (2). Therefore, if we wish the language to support option (2), we need a need a new keyword. I suggest re-using "final". Thus:
       const int FORTY_TWO = 42;       // Not stored anywhere, therefore cannot
take address
       final int FORTY_TWO = 42;       // Stored in ROM, so address can be
taken, but value may not be changed

This brings us to the can of worms that is definition (3). I believe we can do this. I believe it can work. Here's how: The CURRENT situation is that function parameters may be declared in three different ways. These are: (i) in (the default) (ii) out (iii) inout To implement DbC-readonly assertions, we actually need FOUR states. For consistency, these should be: (i) (default) (ii) in (iii) out (iv) inout (default) is what you get if you specify none of the other keywords. For DbC-readonly to work, we only need to state that out, inout, and default, shall work exactly as before (current behavior is unchanged), but new behavior needs to be defined for anything declared using "in". I shall describe this new behavior below. Note though that in addition to its placement before formal function paramters, "in" must also be placeable before member function declarations, like this:
       class A
       {
           in void f()         // a contract that the function will not modify
any of A's member variables
           {
               // do stuff
           }
       }

For reference, the C++ syntax for doing this is:
       class A
       {
           void f() const      // a contract that the function will not modify
any of A's member variables
           {
               // do stuff
           }
       };

Above, I talked about a difference in behavior. The important question is HOW this is going to work? Specifically, what gets passed where? How can the compiler spot a contract violation? These questions I shall answer, now. To the first point, parameters are passed exactly as they are now. Current behavior is suffient. To the second point, given the declaration:
       void f(in SomeObject a)

the following would all be compile-time errors if they occur within the body of the function: (1) a = expression; // illegal always (2) a.m = expression; // illegal always (3) a.g(); // illegal unless g() was declared as in void g() (4) g(a) // illegal unless g() was declared as void g(in SomeObject a) These tests are sufficient to catch all contract violations at compile-time. (The same tests could also be used to verify that "final" objects are not modified). Incidently, the statement:
       this = expression;

should /always/ be illegal, regardless of whether or not the function was declared with "in". Note that currently, that statement is allowed, The consequences of executing it are undefined. CONSEQUENCES If we were starting from scratch, there would be no consequences. But we are not starting from scratch. We already have a large body of code out there, much of which will not immediately compile under this proposed change. There is an immediate consequence for getter functions (properties). All property getter functions would have to be redclared, like this:
       int x() { return x_; }      // BEFORE
       in int x() { return x_; }   // AFTER

Similarly, there is an immediate consequence for the non-assigning operator overloads, which would also have to be redeclared:
       SomeObject opAdd(SomeObject x)          // BEFORE
       in SomeObject opAdd(in SomeObject x)    // AFTER

Then, similarly, you redeclare every other function that requires it, in every file, least-dependent (that is, most low-level) file first. The absolute simplest way to do this is to declare EVERYTHING that isn't "out" or "inout" as "in", and then remove the "in" keyword from things that won't compile. Providing you attack the source code in the right order, this should convert everything that needs it. And it might even show up a few bugs that got missed along the way! CONCLUSION This is achieveable, and simple. The remaining questions are: (i) does the D community want this, given that recoding of a lot of source files will be necessary, and (ii) how does Walter feel about implementing it, given that the illegalities would be relatively easy to spot? OH YEAH - I FORGOT Given the declaration:
       f(out SomeType x)

I would *assume* (though I haven't done the experiment) that either the caller or the callee overwrites any former value of x with the init value of SomeType, before doing anything with x. If it doesn't, it should. Arcane Jill
May 27 2004
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Arcane Jill wrote:
 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function will
 not modify something
 
 The keyword "const" is implemented in D to allow use (1) only.
 
 It has been suggested that the distinction between (1) and (2) could be decided
 by the compiler. Alas, that may not be so. Given the declaration:
 
 
      const int FORTY_TWO = 42;

the expression (&FORTY_TWO) should be illegal in case (1), but legal in case (2). Therefore, if we wish the language to support option (2), we need a need a new keyword.

Why? const int FORTY_TWO=42; means that ist an integer with the value 42 which will never change. Thus &FORTY_TWO is perfectly legal. The distrinction you're talking about is an optimization. When seeing FORTY_TWO being used as a value then the compiler knows that it can safely insert the constant 42 instead. And if the address of FORTY_TWO is NEVER needed then it may even decide to axe the integer object completely. But, this is all transparent to the programmer and completely done behind the scenes by the compiler. So I fail to see the problem. Hauke
May 27 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
 the expression (&FORTY_TWO) should be illegal in case (1), but legal in case
 (2). Therefore, if we wish the language to support option (2), we need a need a
 new keyword. 

Why? const int FORTY_TWO=42; means that ist an integer with the value 42 which will never change. Thus &FORTY_TWO is perfectly legal. The distrinction you're talking about is an optimization. When seeing FORTY_TWO being used as a value then the compiler knows that it can safely insert the constant 42 instead. And if the address of FORTY_TWO is NEVER needed then it may even decide to axe the integer object completely. But, this is all transparent to the programmer and completely done behind the scenes by the compiler. So I fail to see the problem. Hauke

The problem occurs if "const int FORTY_TWO = 42;" occurs in module A, but the expression "&FORTY_TWO" occurs in module B. When compiling module A, how is the compiler to know (without clairvoyance) what module B is going to do? It can't optimize FORTY_TWO away if there's even a /chance/ that some other module might take its address. Yet ... we want it to make that optimization. Don't we? Jill
May 27 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Arcane Jill wrote:
the expression (&FORTY_TWO) should be illegal in case (1), but legal in case
(2). Therefore, if we wish the language to support option (2), we need a need a
new keyword. 

Why? const int FORTY_TWO=42; means that ist an integer with the value 42 which will never change. Thus &FORTY_TWO is perfectly legal. The distrinction you're talking about is an optimization. When seeing FORTY_TWO being used as a value then the compiler knows that it can safely insert the constant 42 instead. And if the address of FORTY_TWO is NEVER needed then it may even decide to axe the integer object completely. But, this is all transparent to the programmer and completely done behind the scenes by the compiler. So I fail to see the problem. Hauke

The problem occurs if "const int FORTY_TWO = 42;" occurs in module A, but the expression "&FORTY_TWO" occurs in module B. When compiling module A, how is the compiler to know (without clairvoyance) what module B is going to do? It can't optimize FORTY_TWO away if there's even a /chance/ that some other module might take its address. Yet ... we want it to make that optimization. Don't we?

I always thought this kind of optimization (throwing away unused entities) is done by the linker. Isn't it? Anyway, I don't think that having some additional integers floating around would be any problem. The additional overhead certainly does not justify introducing two different kinds of const keywords. And if it is a problem for a specialized application you could still let the compiler compile all modules at once. For me this smells like the "register" keyword all over again. Hauke
May 27 2004
parent reply Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c94nff$e11$1 digitaldaemon.com>, Hauke Duden says...
..
 The problem occurs if "const int FORTY_TWO = 42;" occurs in module A, but the
 expression "&FORTY_TWO" occurs in module B. When compiling module A, how is the
 compiler to know (without clairvoyance) what module B is going to do? It can't
 optimize FORTY_TWO away if there's even a /chance/ that some other module might
 take its address. Yet ... we want it to make that optimization. Don't we?

I always thought this kind of optimization (throwing away unused entities) is done by the linker. Isn't it? Anyway, I don't think that having some additional integers floating around would be any problem. The additional overhead certainly does not justify introducing two different kinds of const keywords. And if it is a problem for a specialized application you could still let the compiler compile all modules at once. For me this smells like the "register" keyword all over again. Hauke

In C++ at least, the linker throws away compilation units (files) when no references to them are found. Anything smaller than that is probably not removed by the linker. I spent all day today (at work) moving stuff between compilation units to reduce executable sizes. Compiler experts: What do you think of breaking compilation units up into the smallest possible pieces in the compiler? If the compiler emitted one .o file for each function or method (optionally) and automatically bound them into a .a file for me, I would only pull in methods that were actually called; the recursive effect of this could reduce file sizes massively. I reduced a C++ executable by 30MB by doing this by hand, and I only removed dependency on one library, so I think it could help all-around. (Yes this was debug mode, our release mode binaries are not that large). Kevin
May 27 2004
next sibling parent reply Juan C <Juan_member pathlink.com> writes:
What do you think of breaking compilation units up into the smallest possible
pieces in the compiler?  If the compiler emitted one .o file for each function
or method (optionally) and automatically bound them into a .a file for me, I
would only pull in methods that were actually called; the recursive effect of
this could reduce file sizes massively.

I think this is one of the things I mentioned when I first heard about D. I got into the habit of putting only one function in each file when I worked on a large team using C, and that can be done with C++ too (if I recall correctly). I miss that with C#, but I understand version 2 of C# will allow breaking a class up over several files. Tiny code files offer several benefits to teams. However, I believe the compiler/linker shouldn't do it _for_ you.
May 28 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c97r1k$1v9u$1 digitaldaemon.com>, Juan C says...
What do you think of breaking compilation units up into the smallest possible
pieces in the compiler?  If the compiler emitted one .o file for each function
or method (optionally) and automatically bound them into a .a file for me, I
would only pull in methods that were actually called; the recursive effect of
this could reduce file sizes massively.

I think this is one of the things I mentioned when I first heard about D. I got into the habit of putting only one function in each file when I worked on a large team using C, and that can be done with C++ too (if I recall correctly). I miss that with C#, but I understand version 2 of C# will allow breaking a class up over several files. Tiny code files offer several benefits to teams. However, I believe the compiler/linker shouldn't do it _for_ you.

Out of curiosity, why not? Doing this manually takes a lot of effort, and has no benefit, except for the dubious C-language stoicism of having walked the whole distance on foot and not gotten eaten by a bear (yet). What I want is dependency information to be done for "program elements", be they functions, methods, static strings, or global/module scope data objects. Then only the necessary parts of the code will need to be included. The only (functional) downside I see is the inability to write functions that can only be run from GDB via "call x(4)". Kevin
May 28 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c96kgq$651$1 digitaldaemon.com>, Kevin Bealer says...
Compiler experts:

I don't claim to be a compiler expert, but...
What do you think of breaking compilation units up into the smallest possible
pieces in the compiler?  If the compiler emitted one .o file for each function
or method (optionally) and automatically bound them into a .a file for me, I
would only pull in methods that were actually called; the recursive effect of
this could reduce file sizes massively.

I reduced a C++ executable by 30MB by doing this by hand, and I only removed
dependency on one library, so I think it could help all-around.  (Yes this was
debug mode, our release mode binaries are not that large).

..there is a problem doing this in D. The way it's designed. private stuff has to be in the same *file* as anything which references it, and there is no package level attribute. So we can't even implement the same level of granularity to which we are accustomed in C and C++. For this, and other reasons, I am now convinced there is a stong case for the "package" attribute to exist in D. Arcane Jill
May 29 2004
parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <c99ls1$1lmi$1 digitaldaemon.com>, Arcane Jill says...
In article <c96kgq$651$1 digitaldaemon.com>, Kevin Bealer says...
Compiler experts:

I don't claim to be a compiler expert, but...
What do you think of breaking compilation units up into the smallest possible
pieces in the compiler?  If the compiler emitted one .o file for each function
or method (optionally) and automatically bound them into a .a file for me, I
would only pull in methods that were actually called; the recursive effect of
this could reduce file sizes massively.

I reduced a C++ executable by 30MB by doing this by hand, and I only removed
dependency on one library, so I think it could help all-around.  (Yes this was
debug mode, our release mode binaries are not that large).

..there is a problem doing this in D. The way it's designed. private stuff has to be in the same *file* as anything which references it, and there is no package level attribute. So we can't even implement the same level of granularity to which we are accustomed in C and C++. For this, and other reasons, I am now convinced there is a stong case for the "package" attribute to exist in D. Arcane Jill

I agree, there is a problem with doing it using user-level tools before the compile, but once in the compiler, it could be done in D, C, or C++. Compilers enforce the access attributes at the source level. If it rejects the usage, it produces an error message. If it accepts the usage, then it would still be free to write multiple objects. In C or C++, this change would extend the benefit of using one-file-per-package to all programs, even those that put all code in one file. In D, it may be less beneficial because the virtual table would probably pull in all the .o files, unless the given functions were "final". If you need the benefit in D, you could use heroic measures to get it, by writing classes like this: Module A: class Foo { final uint increase(int Z) { return impl_Foo_increase(x,y,Z); } final uint decrease(int W) { return impl_Foo_decrease(x,y,W); } private: int x,y; }; Module B: uint impl_Foo_increase(inout uint x, inout uint y, inout Z) { .. some code } Module C: uint impl_Foo_decrease(inout uint x, inout uint y, inout W) { .. some code } I know, its a bit ugly. This would also be a way to write C/C++ or C/C++/D programs. (Uh oh -- what have I unleased? Please burn this email!) There are probably people doing this already of course, but without the "final"ity. Kevin
May 30 2004
prev sibling next sibling parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Arcane Jill" wrote
 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function

 not modify something

 The keyword "const" is implemented in D to allow use (1) only.

Possibly misleading AJ. From the documentation: ---------------------------- Const means constant Const is not a type modifier in D, it is a storage class. Hence, the value of a const cannot change. A const declaration can be put in read-only storage, and the optimizer can assume its value never changes. This is unlike C/C++, where since const is a type modifier, the value of a reference to a const can legally change. ---------------------------- This would appear to include (2) as well.
 const int FORTY_TWO = 42;       // Not stored anywhere, therefore cannot

I fail to understand why const is used like this when enum is (apparently) designed explicitly for this purpose. I think this type of const usage should be tossed, along with the Octal prefix everyone loves so much <g>
May 27 2004
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <c95ab4$19a1$1 digitaldaemon.com>, Kris wrote:
 
 "Arcane Jill" wrote
 Possibly misleading AJ. From the documentation:
 
 ----------------------------
 Const means constant
 Const is not a type modifier in D, it is a storage class. Hence, the value
 of a const cannot change. A const declaration can be put in read-only
 storage, and the optimizer can assume its value never changes. This is
 unlike C/C++, where since const is a type modifier, the value of a reference
 to a const can legally change.
 ----------------------------

(Um, and I just have to say that the documentation itself seems to be hinting that values of constant declarations cannot be put into read-only memory in C++, which they can. Const _references_ are a different business.)
 This would appear to include (2) as well.
 
 
 const int FORTY_TWO = 42;       // Not stored anywhere, therefore cannot

I fail to understand why const is used like this when enum is (apparently) designed explicitly for this purpose. I think this type of const usage should be tossed, along with the Octal prefix everyone loves so much <g>

Because enums cannot be used to declare constant floats, character literals, other objects or (indeed) have their address taken. Enums, I think, are designed for the purpose of - well - enumerating. :) -Antti -- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
May 27 2004
parent reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
"Antti Sykäri" wrote
 const int FORTY_TWO = 42;       // Not stored anywhere, therefore



 I fail to understand why const is used like this when enum is


 designed explicitly for this purpose. I think this type of const usage
 should be tossed, along with the Octal prefix everyone loves so much <g>

Because enums cannot be used to declare constant floats, character literals, other objects or (indeed) have their address taken. Enums, I think, are designed for the purpose of - well - enumerating. :) -Antti

Right :-) I guess I wasn't very clear on that one. That particular example from AJ was *only* for those constants that cannot have an address taken. The "read-only" style of const (2) would hande literals, objects, structs etc. If enum cannot handle floats then perhaps it could? It is legal to set a D enum type, but I guess that covers int and char only? Perhaps I'm being naiive ... - Kris
May 27 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <c95pbn$1vov$1 digitaldaemon.com>, Kris says...

That particular example from AJ was *only* for those constants that cannot
have an address taken.

I did give an example, but it was *only* an example. The underlying point was generic. It wasn't practical to give the whole infinity of possible examples. In general, I tend to give the simplest example I can think of. Perhaps a better example would have been:
       const int[10000] = 
           // loads of data

In any case, it was not I who claimed that this was a problem, I merely repeated it. Another poster (forgive me, I can't remember who) was interested in ROM storage for firmware and stuff. To be honest, this isn't a big deal to me either. By the DbC problem is. Jill
May 27 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I was the poster vis-a-vis RO segments, but I thought your original post
made the correct distinction AJ: here it is again

Summary - the story so far:
Three uses of const have been identified in C++
(1) To declare a complile-time constant
(2) To declare an instance of something which needs to be stored in ROM
(3) As part of Design-By-Contract, to specify a contract that a function
will
not modify something

I thought you were suggesting (1) should be things you cannot take the
address of? If so, I'd fully agree. I tend to equate (1) with enum, since
they are compile-time constants.

(2) doesn't *need* to be stored in ROM, but it declares the instance as RO
and is therefore a ROM candidate. This, I thought, would have included your
{const int[10000] = ...} as noted below, for which you should be able to
take an address of. However, your post below is in the context of
non-addressable items like (1) ... Did you mean {final int [10000] = }
instead, per your suggested syntax change, or are you saying that (1) should
be addressable?

Confused again;

- Kris


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c95qlo$21ru$1 digitaldaemon.com...
 In article <c95pbn$1vov$1 digitaldaemon.com>, Kris says...

That particular example from AJ was *only* for those constants that


have an address taken.

I did give an example, but it was *only* an example. The underlying point

 generic. It wasn't practical to give the whole infinity of possible

 general, I tend to give the simplest example I can think of.

 Perhaps a better example would have been:

       const int[10000] =
           // loads of data

In any case, it was not I who claimed that this was a problem, I merely

 it. Another poster (forgive me, I can't remember who) was interested in

 storage for firmware and stuff.

 To be honest, this isn't a big deal to me either. By the DbC problem is.

 Jill

May 27 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
I think the default behaviour, i.e. that of 'in' *should* be changed.

I think it should:
1- pass by reference (even for structs)
2- enforce what you have mentioned below, compile time checking that the 
variable is not changed.

The reasoning for 1 is that typically you do not want to copy-in a struct, 
doing so for a large struct is in-efficient, and if you want to modify it 
then either:
a- it is incorrectly defined as an 'in' parameter
b- you only want to do so for the functions scope so why not:

struct foo {
   int a;
   int b;
   int c;
}

int foobar(in foo _abc) {
   foo abc = _abc;
}

The reasoning for 2 is an obvious dbc rule, if a variable is not an out or 
inout then it should not get modified by the function.


I also think if you replace the word 'in' below with 'const' it looks like 
what you have said *is* exactly what const is in C/C++..


I agree there needs to be some way of saying that a method of a class does 
not modify it's members, so it can then be used on/with an 'in' parameter, 
why not:

class A {
   void foo(in this, int a) {  //does not modify members of A
   }
   void foo(int a) {  //does modify members of A (or rather does not 
guarantee not to)
   }
}

in other words an *optional* definition for the this parameter.


I realise my proposed change to the behaviour of 'in' will possibly break 
existing code which is expecting the copy-in behaviour of structs.. but I 
believe it is the *right* way to do it, and as D is not set in stone yet..


On Thu, 27 May 2004 08:55:21 +0000 (UTC), Arcane Jill 
<Arcane_member pathlink.com> wrote:
 I have given a lot of thought to the whole "const" thing, and it seems 
 to me
 that there is a way around this that will keep everybody happy. (It was 
 not I
 who thought of this, by the way - I'm just clarifying).

 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function 
 will
 not modify something

 The keyword "const" is implemented in D to allow use (1) only.

 It has been suggested that the distinction between (1) and (2) could be 
 decided
 by the compiler. Alas, that may not be so. Given the declaration:

       const int FORTY_TWO = 42;

the expression (&FORTY_TWO) should be illegal in case (1), but legal in case (2). Therefore, if we wish the language to support option (2), we need a need a new keyword. I suggest re-using "final". Thus:
       const int FORTY_TWO = 42;       // Not stored anywhere, therefore 
 cannot take address
       final int FORTY_TWO = 42;       // Stored in ROM, so address can 
 be taken, but value may not be changed

This brings us to the can of worms that is definition (3). I believe we can do this. I believe it can work. Here's how: The CURRENT situation is that function parameters may be declared in three different ways. These are: (i) in (the default) (ii) out (iii) inout To implement DbC-readonly assertions, we actually need FOUR states. For consistency, these should be: (i) (default) (ii) in (iii) out (iv) inout (default) is what you get if you specify none of the other keywords. For DbC-readonly to work, we only need to state that out, inout, and default, shall work exactly as before (current behavior is unchanged), but new behavior needs to be defined for anything declared using "in". I shall describe this new behavior below. Note though that in addition to its placement before formal function paramters, "in" must also be placeable before member function declarations, like this:
       class A
       {
           in void f()         // a contract that the function will not 
 modify any of A's member variables
           {
               // do stuff
           }
       }

For reference, the C++ syntax for doing this is:
       class A
       {
           void f() const      // a contract that the function will not 
 modify any of A's member variables
           {
               // do stuff
           }
       };

Above, I talked about a difference in behavior. The important question is HOW this is going to work? Specifically, what gets passed where? How can the compiler spot a contract violation? These questions I shall answer, now. To the first point, parameters are passed exactly as they are now. Current behavior is suffient. To the second point, given the declaration:
       void f(in SomeObject a)

the following would all be compile-time errors if they occur within the body of the function: (1) a = expression; // illegal always (2) a.m = expression; // illegal always (3) a.g(); // illegal unless g() was declared as in void g() (4) g(a) // illegal unless g() was declared as void g(in SomeObject a) These tests are sufficient to catch all contract violations at compile-time. (The same tests could also be used to verify that "final" objects are not modified). Incidently, the statement:
       this = expression;

should /always/ be illegal, regardless of whether or not the function was declared with "in". Note that currently, that statement is allowed, The consequences of executing it are undefined. CONSEQUENCES If we were starting from scratch, there would be no consequences. But we are not starting from scratch. We already have a large body of code out there, much of which will not immediately compile under this proposed change. There is an immediate consequence for getter functions (properties). All property getter functions would have to be redclared, like this:
       int x() { return x_; }      // BEFORE
       in int x() { return x_; }   // AFTER

Similarly, there is an immediate consequence for the non-assigning operator overloads, which would also have to be redeclared:
       SomeObject opAdd(SomeObject x)          // BEFORE
       in SomeObject opAdd(in SomeObject x)    // AFTER

Then, similarly, you redeclare every other function that requires it, in every file, least-dependent (that is, most low-level) file first. The absolute simplest way to do this is to declare EVERYTHING that isn't "out" or "inout" as "in", and then remove the "in" keyword from things that won't compile. Providing you attack the source code in the right order, this should convert everything that needs it. And it might even show up a few bugs that got missed along the way! CONCLUSION This is achieveable, and simple. The remaining questions are: (i) does the D community want this, given that recoding of a lot of source files will be necessary, and (ii) how does Walter feel about implementing it, given that the illegalities would be relatively easy to spot? OH YEAH - I FORGOT Given the declaration:
       f(out SomeType x)

I would *assume* (though I haven't done the experiment) that either the caller or the callee overwrites any former value of x with the init value of SomeType, before doing anything with x. If it doesn't, it should. Arcane Jill

-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
May 27 2004
prev sibling next sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
This proposition has merit. Instead of advocating "const" to the
language (like a lot of people, including myself until I started to
doubt myself, have done) it extends the in/out/inout concept so that it
would be semantically as strong as "const" is in C/C++.

Just adding const would make the language clunky and complicated;
implementing this proposition might be just the right solution.

(There are of course the troubles that come with const as well, I think.
Something about overload resolution or something. Anyway, it's been one
argument against const.)

-Antti

In article <c94adp$20fe$1 digitaldaemon.com>, Arcane Jill wrote:
 I have given a lot of thought to the whole "const" thing, and it seems to me
 that there is a way around this that will keep everybody happy. (It was not I
 who thought of this, by the way - I'm just clarifying).

[...]
 (3) As part of Design-By-Contract, to specify a contract that a function will
 not modify something

[...]
 This brings us to the can of worms that is definition (3). I believe we can do
 this. I believe it can work. Here's how:
 
 The CURRENT situation is that function parameters may be declared in three
 different ways. These are:
 
 (i)   in (the default)
 (ii)  out
 (iii) inout
 
 To implement DbC-readonly assertions, we actually need FOUR states. For
 consistency, these should be:
 
 (i)   (default)
 (ii)  in
 (iii) out
 (iv)  inout
 
 (default) is what you get if you specify none of the other keywords. For
 DbC-readonly to work, we only need to state that out, inout, and
 default, shall work exactly as before (current behavior is unchanged),
 but new behavior needs to be defined for anything declared using "in".
 I shall describe this new behavior below.
 
 Note though that in addition to its placement before formal function paramters,
 "in" must also be placeable before member function declarations, like this:
 
       class A
       {
           in void f()         // a contract that the function will not modify
any of A's member variables
           {
               // do stuff
           }
       }

For reference, the C++ syntax for doing this is:
       class A
       {
           void f() const      // a contract that the function will not modify
any of A's member variables
           {
               // do stuff
           }
       };

Above, I talked about a difference in behavior. The important question is HOW this is going to work? Specifically, what gets passed where? How can the compiler spot a contract violation? These questions I shall answer, now. To the first point, parameters are passed exactly as they are now. Current behavior is suffient. To the second point, given the declaration:
       void f(in SomeObject a)

the following would all be compile-time errors if they occur within the body of the function: (1) a = expression; // illegal always (2) a.m = expression; // illegal always (3) a.g(); // illegal unless g() was declared as in void g() (4) g(a) // illegal unless g() was declared as void g(in SomeObject a) These tests are sufficient to catch all contract violations at compile-time. (The same tests could also be used to verify that "final" objects are not modified). Incidently, the statement:
       this = expression;

should /always/ be illegal, regardless of whether or not the function was declared with "in". Note that currently, that statement is allowed, The consequences of executing it are undefined. CONSEQUENCES If we were starting from scratch, there would be no consequences. But we are not starting from scratch. We already have a large body of code out there, much of which will not immediately compile under this proposed change. There is an immediate consequence for getter functions (properties). All property getter functions would have to be redclared, like this:
       int x() { return x_; }      // BEFORE
       in int x() { return x_; }   // AFTER

Similarly, there is an immediate consequence for the non-assigning operator overloads, which would also have to be redeclared:
       SomeObject opAdd(SomeObject x)          // BEFORE
       in SomeObject opAdd(in SomeObject x)    // AFTER

Then, similarly, you redeclare every other function that requires it, in every file, least-dependent (that is, most low-level) file first. The absolute simplest way to do this is to declare EVERYTHING that isn't "out" or "inout" as "in", and then remove the "in" keyword from things that won't compile. Providing you attack the source code in the right order, this should convert everything that needs it. And it might even show up a few bugs that got missed along the way! CONCLUSION This is achieveable, and simple. The remaining questions are: (i) does the D community want this, given that recoding of a lot of source files will be necessary, and (ii) how does Walter feel about implementing it, given that the illegalities would be relatively easy to spot? OH YEAH - I FORGOT Given the declaration:
       f(out SomeType x)

I would *assume* (though I haven't done the experiment) that either the caller or the callee overwrites any former value of x with the init value of SomeType, before doing anything with x. If it doesn't, it should. Arcane Jill

-- I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
May 27 2004
prev sibling next sibling parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
I'd like to attempt a further clarification regarding the three types of
'const' usage identified:

1) compile-time constants, such as enum. You cannot take the address of
these.

2) final instances of arrays, structs, literals, objects, whatever. The
memory occupied by these should likely be initialized at the point of
declaration, and cannot be changed once set. It is conceivable (and often
necessary) to take the address of these, and it might be useful to think of
them as ROM candidates. Note that final objects might be a bit tricky.

3) DbC constraints that prevent an argument from being internally modified,
either wholly or in specific ways. In addition, there's the issue of
pass-by-value/pass-by-reference for structs that muddies the keyword water
somewhat within this arena.

- Kris


"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c94adp$20fe$1 digitaldaemon.com...
 I have given a lot of thought to the whole "const" thing, and it seems to

 that there is a way around this that will keep everybody happy. (It was

 who thought of this, by the way - I'm just clarifying).

 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function

 not modify something

 The keyword "const" is implemented in D to allow use (1) only.

 It has been suggested that the distinction between (1) and (2) could be

 by the compiler. Alas, that may not be so. Given the declaration:

       const int FORTY_TWO = 42;

the expression (&FORTY_TWO) should be illegal in case (1), but legal in

 (2). Therefore, if we wish the language to support option (2), we need a

 new keyword. I suggest re-using "final". Thus:

       const int FORTY_TWO = 42;       // Not stored anywhere, therefore


       final int FORTY_TWO = 42;       // Stored in ROM, so address can


 This brings us to the can of worms that is definition (3). I believe we

 this. I believe it can work. Here's how:

 The CURRENT situation is that function parameters may be declared in three
 different ways. These are:

 (i)   in (the default)
 (ii)  out
 (iii) inout

 To implement DbC-readonly assertions, we actually need FOUR states. For
 consistency, these should be:

 (i)   (default)
 (ii)  in
 (iii) out
 (iv)  inout

 (default) is what you get if you specify none of the other keywords. For
 DbC-readonly to work, we only need to state that out, inout, and default,

 work exactly as before (current behavior is unchanged), but new behavior

 to be defined for anything declared using "in". I shall describe this new
 behavior below.

 Note though that in addition to its placement before formal function

 "in" must also be placeable before member function declarations, like

       class A
       {
           in void f()         // a contract that the function will not


           {
               // do stuff
           }
       }

For reference, the C++ syntax for doing this is:
       class A
       {
           void f() const      // a contract that the function will not


           {
               // do stuff
           }
       };

Above, I talked about a difference in behavior. The important question is

 this is going to work? Specifically, what gets passed where? How can the
 compiler spot a contract violation? These questions I shall answer, now.

 To the first point, parameters are passed exactly as they are now. Current
 behavior is suffient.

 To the second point, given the declaration:

       void f(in SomeObject a)

the following would all be compile-time errors if they occur within the

 the function:

 (1)     a = expression;     // illegal always
 (2)     a.m = expression;   // illegal always
 (3)     a.g();              // illegal unless g() was declared as in void

 (4)     g(a)                // illegal unless g() was declared as void

 SomeObject a)

 These tests are sufficient to catch all contract violations at

 (The same tests could also be used to verify that "final" objects are not
 modified).

 Incidently, the statement:

       this = expression;

should /always/ be illegal, regardless of whether or not the function was declared with "in". Note that currently, that statement is allowed, The consequences of executing it are undefined. CONSEQUENCES If we were starting from scratch, there would be no consequences. But we

 starting from scratch. We already have a large body of code out there,

 which will not immediately compile under this proposed change.

 There is an immediate consequence for getter functions (properties). All
 property getter functions would have to be redclared, like this:

       int x() { return x_; }      // BEFORE
       in int x() { return x_; }   // AFTER

Similarly, there is an immediate consequence for the non-assigning

 overloads, which would also have to be redeclared:

       SomeObject opAdd(SomeObject x)          // BEFORE
       in SomeObject opAdd(in SomeObject x)    // AFTER

Then, similarly, you redeclare every other function that requires it, in

 file, least-dependent (that is, most low-level) file first. The absolute
 simplest way to do this is to declare EVERYTHING that isn't "out" or

 "in", and then remove the "in" keyword from things that won't compile.

 you attack the source code in the right order, this should convert

 that needs it. And it might even show up a few bugs that got missed along

 way!

 CONCLUSION

 This is achieveable, and simple. The remaining questions are: (i) does the

 community want this, given that recoding of a lot of source files will be
 necessary, and (ii) how does Walter feel about implementing it, given that

 illegalities would be relatively easy to spot?

 OH YEAH - I FORGOT

 Given the declaration:

       f(out SomeType x)

I would *assume* (though I haven't done the experiment) that either the

 or the callee overwrites any former value of x with the init value of

 before doing anything with x. If it doesn't, it should.


 Arcane Jill

May 27 2004
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 27 May 2004 08:55:21 +0000 (UTC), Arcane Jill wrote:

 I have given a lot of thought to the whole "const" thing, and it seems to me
 that there is a way around this that will keep everybody happy. (It was not I
 who thought of this, by the way - I'm just clarifying).
 
 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function will
 not modify something
 
 The keyword "const" is implemented in D to allow use (1) only.

So this idea is a LITERAL value that does not take up any RAM at runtime, right? If so, maybe the keyword 'literal' could be used instead of 'const'. literal FORTY_TWO = 42; Note that the data type information is redundant as it is always the same datatype as the RHS expression. literal PI = 3.1415926535897932384626433832795; Of course if we had array and structure literals this would be nice too. struct Point{ int X,Y;}; literal STARTPOINT = Point(X=5,Y=10); but let's not get ahead of ourselves ;-) -- Derek 28/May/04 10:06:44 AM
May 27 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Interesting. I look forward to hearing what Walter thinks of this, but I'm going
to keep breathing while I wait. <G>

"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:c94adp$20fe$1 digitaldaemon.com...
 I have given a lot of thought to the whole "const" thing, and it seems to me
 that there is a way around this that will keep everybody happy. (It was not I
 who thought of this, by the way - I'm just clarifying).

 Summary - the story so far:
 Three uses of const have been identified in C++
 (1) To declare a complile-time constant
 (2) To declare an instance of something which needs to be stored in ROM
 (3) As part of Design-By-Contract, to specify a contract that a function will
 not modify something

 The keyword "const" is implemented in D to allow use (1) only.

 It has been suggested that the distinction between (1) and (2) could be decided
 by the compiler. Alas, that may not be so. Given the declaration:

       const int FORTY_TWO = 42;

the expression (&FORTY_TWO) should be illegal in case (1), but legal in case (2). Therefore, if we wish the language to support option (2), we need a need a new keyword. I suggest re-using "final". Thus:
       const int FORTY_TWO = 42;       // Not stored anywhere, therefore


       final int FORTY_TWO = 42;       // Stored in ROM, so address can be


 This brings us to the can of worms that is definition (3). I believe we can do
 this. I believe it can work. Here's how:

 The CURRENT situation is that function parameters may be declared in three
 different ways. These are:

 (i)   in (the default)
 (ii)  out
 (iii) inout

 To implement DbC-readonly assertions, we actually need FOUR states. For
 consistency, these should be:

 (i)   (default)
 (ii)  in
 (iii) out
 (iv)  inout

 (default) is what you get if you specify none of the other keywords. For
 DbC-readonly to work, we only need to state that out, inout, and default, shall
 work exactly as before (current behavior is unchanged), but new behavior needs
 to be defined for anything declared using "in". I shall describe this new
 behavior below.

 Note though that in addition to its placement before formal function paramters,
 "in" must also be placeable before member function declarations, like this:

       class A
       {
           in void f()         // a contract that the function will not modify


           {
               // do stuff
           }
       }

For reference, the C++ syntax for doing this is:
       class A
       {
           void f() const      // a contract that the function will not modify


           {
               // do stuff
           }
       };

Above, I talked about a difference in behavior. The important question is HOW this is going to work? Specifically, what gets passed where? How can the compiler spot a contract violation? These questions I shall answer, now. To the first point, parameters are passed exactly as they are now. Current behavior is suffient. To the second point, given the declaration:
       void f(in SomeObject a)

the following would all be compile-time errors if they occur within the body of the function: (1) a = expression; // illegal always (2) a.m = expression; // illegal always (3) a.g(); // illegal unless g() was declared as in void g() (4) g(a) // illegal unless g() was declared as void g(in SomeObject a) These tests are sufficient to catch all contract violations at compile-time. (The same tests could also be used to verify that "final" objects are not modified). Incidently, the statement:
       this = expression;

should /always/ be illegal, regardless of whether or not the function was declared with "in". Note that currently, that statement is allowed, The consequences of executing it are undefined. CONSEQUENCES If we were starting from scratch, there would be no consequences. But we are

 starting from scratch. We already have a large body of code out there, much of
 which will not immediately compile under this proposed change.

 There is an immediate consequence for getter functions (properties). All
 property getter functions would have to be redclared, like this:

       int x() { return x_; }      // BEFORE
       in int x() { return x_; }   // AFTER

Similarly, there is an immediate consequence for the non-assigning operator overloads, which would also have to be redeclared:
       SomeObject opAdd(SomeObject x)          // BEFORE
       in SomeObject opAdd(in SomeObject x)    // AFTER

Then, similarly, you redeclare every other function that requires it, in every file, least-dependent (that is, most low-level) file first. The absolute simplest way to do this is to declare EVERYTHING that isn't "out" or "inout" as "in", and then remove the "in" keyword from things that won't compile.

 you attack the source code in the right order, this should convert everything
 that needs it. And it might even show up a few bugs that got missed along the
 way!

 CONCLUSION

 This is achieveable, and simple. The remaining questions are: (i) does the D
 community want this, given that recoding of a lot of source files will be
 necessary, and (ii) how does Walter feel about implementing it, given that the
 illegalities would be relatively easy to spot?

 OH YEAH - I FORGOT

 Given the declaration:

       f(out SomeType x)

I would *assume* (though I haven't done the experiment) that either the caller or the callee overwrites any former value of x with the init value of SomeType, before doing anything with x. If it doesn't, it should. Arcane Jill

Jun 04 2004