• ore-sama (26/26) Oct 06 2008 I wanted to use const system, but the kitchen sink syndrome SUDDENLY kil...
• Jason House (4/36) Oct 06 2008 What about the following?
• Denis Koroskin (7/17) Oct 06 2008 Other suggestion:

ore-sama <spam here.lot> writes:

I wanted to use const system, but the kitchen sink syndrome SUDDENLY killed me
:(
There is return storage class attribute

const(char[]) capitalize(return const(char[]) s) { ... }

but it's not very intuitive: surprisingly return type is NOT what it looks like
and one have to read the entire signature to figure out that the return type is
not really const.
Rather than that we want here one parameter with *optional* constness and
return type *inheriting* this constness and these tend to be deemed as *two*
different, though related, operations. And as Bill Baxter pointed out (
http://d.puremagic.com/issues/show_bug.cgi?id=2094#c9 ) we would like to extend
it to invariant inheritance. So this gets a little more complicated than mere
attribute. So a few proposals from me.

Case 1. Straight-forward approach. Huh? and bang! notation.
const!(str)(char[]) capitalize(const?(char[]) str) { ... }
So the second huh?const declares mimic const type and the first bang!const
extracts constness from parameter and applies it to the return type.
* return type explicitly indicates what it does.
* optional const and inheriting const are different independent entities.

Case 2. We need only const-extraction operator... pseudo-operator?
const!(str)(char[]) capitalize(const!(str)(char[]) str) { ... }
Constness of parameter gets equal to constness of argument!
* two operations reduced to one
* more context-independent.

Case 3. Quantum const.
const?(char[]) capitalize(const?(char[]) s) { ... }
Like huh?const, but all of them from the same signature enter entangled state
(with indefinite constness) and trigger simultaneously (constness gets
determined) on function call (interaction with with the world). This rationale
came from quantum mechanics :)))
* possibly a third flavor of const
* extension on invariant can be done also in terms of quantum mechanics: just
say const? can take 3 values: mutable, const and invariant, but its value is
indefinite until function call.
* D will be as complicated as quantum mechanics is. Joke.

P.S. this can be easily extended for member functions
const(char[]) capitalize() return const
const!(this)(char[]) capitalize()  //no huh?const because this is already
huh?const
const!(this)(char[]) capitalize()  //the same for operator form
const?(char[]) capitalize() const?  //or we can also deem this as
quantum-consted (of indefinite constness).

Jason House <jason.james.house gmail.com> writes:

ore-sama Wrote:

 I wanted to use const system, but the kitchen sink syndrome SUDDENLY killed me
:(
 There is return storage class attribute
 
 const(char[]) capitalize(return const(char[]) s) { ... }


What about the following?
return(char[]) capitalize(return(char[]) s){ ... }

It's shorter, supports both const and invariant, and is clear when looking at
the return type




 
 but it's not very intuitive: surprisingly return type is NOT what it looks
like and one have to read the entire signature to figure out that the return
type is not really const.
 Rather than that we want here one parameter with *optional* constness and
return type *inheriting* this constness and these tend to be deemed as *two*
different, though related, operations. And as Bill Baxter pointed out (
http://d.puremagic.com/issues/show_bug.cgi?id=2094#c9 ) we would like to extend
it to invariant inheritance. So this gets a little more complicated than mere
attribute. So a few proposals from me.
 
 Case 1. Straight-forward approach. Huh? and bang! notation.
 const!(str)(char[]) capitalize(const?(char[]) str) { ... }
 So the second huh?const declares mimic const type and the first bang!const
extracts constness from parameter and applies it to the return type.
 * return type explicitly indicates what it does.
 * optional const and inheriting const are different independent entities.
 
 Case 2. We need only const-extraction operator... pseudo-operator?
 const!(str)(char[]) capitalize(const!(str)(char[]) str) { ... }
 Constness of parameter gets equal to constness of argument!
 * two operations reduced to one
 * more context-independent.
 
 Case 3. Quantum const.
 const?(char[]) capitalize(const?(char[]) s) { ... }
 Like huh?const, but all of them from the same signature enter entangled state
(with indefinite constness) and trigger simultaneously (constness gets
determined) on function call (interaction with with the world). This rationale
came from quantum mechanics :)))
 * possibly a third flavor of const
 * extension on invariant can be done also in terms of quantum mechanics: just
say const? can take 3 values: mutable, const and invariant, but its value is
indefinite until function call.
 * D will be as complicated as quantum mechanics is. Joke.
 
 P.S. this can be easily extended for member functions
 const(char[]) capitalize() return const
 const!(this)(char[]) capitalize()  //no huh?const because this is already
huh?const
 const!(this)(char[]) capitalize()  //the same for operator form
 const?(char[]) capitalize() const?  //or we can also deem this as
quantum-consted (of indefinite constness).

"Denis Koroskin" <2korden gmail.com> writes:

On Tue, 07 Oct 2008 03:41:30 +0400, Jason House  
<jason.james.house gmail.com> wrote:

 ore-sama Wrote:

 I wanted to use const system, but the kitchen sink syndrome SUDDENLY  
 killed me :(
 There is return storage class attribute

 const(char[]) capitalize(return const(char[]) s) { ... }


 What about the following?
 return(char[]) capitalize(return(char[]) s){ ... }

 It's shorter, supports both const and invariant, and is clear when  
 looking at the return type

Other suggestion:
sameconst(char[]) capitalize(sameconst(char[]) s){ ... }

or just:
same(char[]) capitalize(same(char[]) s){ ... } // this one is even shorter!

It says that both input and output parameters have same constness.