const debacle

Janice Caron caron800 at googlemail.com
Mon Mar 24 04:56:35 PDT 2008


On 24/03/2008, Christopher Wright <dhasenan at gmail.com> wrote:
> Janice Caron wrote:
>  > On 24/03/2008, Jarrod <qwerty at ytre.wq> wrote:
>
> >>  I know everyone is throwing in some kind of template or overload idea,
>  >>  but mine is a little more simple: Change 'in'. Use 'in' to define a
>  >>  function that will take a value and not change it, but make no guarantees
>  >>  about the return type
>
> > I'm going to have to join forces with Walter on this one. It doesn't
>  > matter what syntax you use to declare function parameters - any such
>  > declaration, whatever the syntax, /will break const correctness/.
>
>
> I think your suggestions are fundamentally broken.

Whoa - hang on here. You're going to have to define "fundamentally
broken". When Walter says "fundamentally broken" he usually means "not
const correct". What do you mean?

Though various options have been discussed, and various suggestions
have been floated, including by me, I am now recommending one, and
only one, solution, which is for the function to return a pair of
indeces. This suggestion supercedes any previous suggestions I may
have made. And I guarantee you that returning a pair of indeces is not
broken in any respect.


> If I want a contract
> with a method, I shouldn't have to change my representation of my data.

I wasn't aware that I had suggested changing representation of data.


>  This method should be const-correct by having parameters that are const
>  for however long it's running. After that, everything goes back to the
>  caller, which has different contracts. The caller can break contracts
>  that the callee is bound to because they are different entities with
>  different contracts.

In general, you /cannot/ convert const to mutable in a return
statement. For example:

    const(char)[] g = "hello".dup; // A global variable

    char[] f()
    {
        return g; // NOT acceptable
    }

We can argue that a slice of an input parameter should be a special
case, but why bother? It's hard for the compiler to prove, and
returning indeces instead is trivially easy.



More information about the Digitalmars-d mailing list