Hiya. Sometimes when i`m concerned bout safety, i`d like to have sth like this:

void func(int &param)
{
// do some stuff
const int &foo = param;

forget param;  /* or better name ;) this seems like INTERCAL, but it would make
param unavailable */
// do const stuff with foo
}

this doesnt make much sense with int`s cuz i could make another int instead of a
reference, but in case of more compilcated cases it would be cool cuz it would
make it possible e.g. to make some object const :)
sorry for repostin if this feature is already in the language, i havent read all
the specs... but i see that D is gonna be a beautiful language, this is unusual
since i dont like anything but C++ :)

Keep up the good work

In article <bpl0dv$1m9m$1@digitaldaemon.com>, Heretic wrote:
> Hiya. Sometimes when i`m concerned bout safety, i`d like to have sth like this:
> 
> void func(int &param)
> {
>   // do some stuff
>   const int &foo = param;
> 
>   forget param;  /* or better name ;) this seems like INTERCAL, but it
>                     would make param unavailable */
>   // do const stuff with foo
> }

You mean like:

void func_impl(const int &param)
{
  // do const stuff with foo
}

void func(int &param)
{
  func_impl(param);
}

But this is of course be C++; D doesn't have const (at the moment at least). In D you could use a nested function.

-Antti

Antti Sykäri wrote:

> In article <bpl0dv$1m9m$1@digitaldaemon.com>, Heretic wrote:
> 

> 
> You mean like:
> 
> void func_impl(const int &param)
> {
>   // do const stuff with foo
> }
> 
> void func(int &param)
> {
>   func_impl(param);
> }
> 
> But this is of course be C++; D doesn't have const (at the moment at
> least). In D you could use a nested function.
> 
> -Antti

Question for you.  I really don't like how C++ does const handling for
methods because it is not very intuitive, and causes a lot of code duplication.

For instance:

const void func(const int &param) const
{
   //do const stuff with foo
}

has three distinct meanings for "const".

The first const means that this function implementation will not change.
The second const means that the parameter is a constant parameter (actually
in this case I believe the reference is constant, not the item being
referenced).
The last const means that the function will be available as a method when
the object is used as a constant--but not when the object is used as a
variable.

In Java there is the same type of overloaded keyword named "final".  It
essentially mimics the first two cases of "const" listed above.  There is
no consept of a method used on a non-modifiable (aka const) object.  There
is only the concept of a read only pointer to an object.

Neither of these is ideal.  With Java, if you want a read only object, you
must create a class that is initialized in the constructor and the class
writer must take care not to expose any methods that alter the object's
state.  For a couple examples there is the java.lang.String and java.util.Date
classes.  With C++ you need a pair of methods that do essentially the same
thing, even though the bulk of it is similar.  If there is supposed to be
an automatic fallback on const methods for variable objects then at the very
least Microsoft's compiler was broken.

I occasionally share the same paranoia.

I have a type in STLSoft called inert, in stlsoft_inert.h, that does this.

void func(int &param)
{
  const int &foo = param;
  inert    param;


  . . .
}


I have to say, however, that I think I've only used it about three times.

;)


-- 
Matthew Wilson

STLSoft moderator (http://www.stlsoft.org)
Contributing editor, C/C++ Users Journal
(www.synesis.com.au/articles.html#columns)

"I can't sleep nights till I found out who hurled what ball through what apparatus" -- Dr Niles Crane

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



"Heretic" <Heretic_member@pathlink.com> wrote in message news:bpl0dv$1m9m$1@digitaldaemon.com...
> Hiya. Sometimes when i`m concerned bout safety, i`d like to have sth like
this:
>
> void func(int &param)
> {
> // do some stuff
> const int &foo = param;
>
> forget param;  /* or better name ;) this seems like INTERCAL, but it would
make
> param unavailable */
> // do const stuff with foo
> }
>
> this doesnt make much sense with int`s cuz i could make another int
instead of a
> reference, but in case of more compilcated cases it would be cool cuz it
would
> make it possible e.g. to make some object const :)
> sorry for repostin if this feature is already in the language, i havent
read all
> the specs... but i see that D is gonna be a beautiful language, this is
unusual
> since i dont like anything but C++ :)
>
> Keep up the good work
>
>

"Berin Loritsch" <bloritsch@d-haven.org> wrote in message news:bpldem$2943$1@digitaldaemon.com...
> Antti Sykäri wrote:
>
> > In article <bpl0dv$1m9m$1@digitaldaemon.com>, Heretic wrote:
> >
>
> >
> > You mean like:
> >
> > void func_impl(const int &param)
> > {
> >   // do const stuff with foo
> > }
> >
> > void func(int &param)
> > {
> >   func_impl(param);
> > }
> >
> > But this is of course be C++; D doesn't have const (at the moment at least). In D you could use a nested function.
> >
> > -Antti
>
> Question for you.  I really don't like how C++ does const handling for methods because it is not very intuitive, and causes a lot of code
duplication.
>
> For instance:
>
> const void func(const int &param) const
> {
>     //do const stuff with foo
> }
>
> has three distinct meanings for "const".
>
> The first const means that this function implementation will not change.

This is not C++.

> The second const means that the parameter is a constant parameter
(actually
> in this case I believe the reference is constant, not the item being
> referenced).
> The last const means that the function will be available as a method when
> the object is used as a constant--but not when the object is used as a
> variable.
>
> In Java there is the same type of overloaded keyword named "final".  It essentially mimics the first two cases of "const" listed above.  There is no consept of a method used on a non-modifiable (aka const) object.  There is only the concept of a read only pointer to an object.
>
> Neither of these is ideal.  With Java, if you want a read only object, you must create a class that is initialized in the constructor and the class writer must take care not to expose any methods that alter the object's state.  For a couple examples there is the java.lang.String and
java.util.Date
> classes.  With C++ you need a pair of methods that do essentially the same thing, even though the bulk of it is similar.  If there is supposed to be an automatic fallback on const methods for variable objects then at the
very
> least Microsoft's compiler was broken.

There is not. Two overloads that differ only in const-ness are selected with respect to the const-ness of the object/reference/ptr on which they're called

Matthew Wilson wrote:

> "Berin Loritsch" <bloritsch@d-haven.org> wrote in message
> news:bpldem$2943$1@digitaldaemon.com...
> 

>>classes.  With C++ you need a pair of methods that do essentially the same
>>thing, even though the bulk of it is similar.  If there is supposed to be
>>an automatic fallback on const methods for variable objects then at the
> 
> very
> 
>>least Microsoft's compiler was broken.
> 
> 
> There is not. Two overloads that differ only in const-ness are selected with
> respect to the const-ness of the object/reference/ptr on which they're
> called
> 
> 

RIght, and this is counterintuitive.

I would favor something that at the very least says "this reference will not
change".  IOW, if I have a method like this:

void myMethod(final int arg) {
    // illegal
    arg = 5;
}

void myMethod(final string &arg) {
    // illegal
    arg = "";
}


Anyhoo, I am just a neophyte with D.  All I know is what I like based on
experience with C++/Java