The only thing I can think of:

struct Once(T)
{
    this(T val)
    {
        i = val;
    }

    immutable T i;
    alias i this;
}

void main()
{
    Once!int i = 1;  // ok
    i = 4;  // ng
}

However it seems I've found a little hole in the system:

void foo(ref int x)
{
    x = 2;
}

void main()
{
    Once!int i = 1;  // ok
    foo(i);
    assert(i == 1);  // fail, changed to 2
}

Is this reported somewhere?

On 11/21/11 1:17 PM, Kapps wrote:
> For one reason, public fields that lack a set without having to create a
> backing field, followed by a bulky property. It does sound lazy, but
> when it's something you have to repeat many times, it gets annoying.
>
> On 21/11/2011 9:43 AM, Ary Manzana wrote:
>> On 11/21/11 11:04 AM, Alex Rønne Petersen wrote:
>>> Hi,
>>>
>>> Is there any way to make a variable single-assignment, regardless of its
>>> type? I.e.:
>>>
>>> void foo()
>>> {
>>> <some magical keyword?> int i = 0;
>>> i = 2; // Error: i cannot be reassigned
>>> }
>>>
>>> I realize const and immutable will do this, but they are transitive and
>>> infect the type, which I do *not* want. I simply want the variable to be
>>> single-assignment. Is it possible?
>>>
>>> - Alex
>>
>> Why do you want that?
>

But that's different from what you asked. In your example "i" is a local variable. You want that for public fields...

In Ruby you'd do:

attr_reader :foo

Isn't some standard mixin in D for that? (if the accesor method gets inline then the method call shouldn't affect the performance)

On 21/11/2011 20:06, Jesse Phillips wrote:
> What you are describing is Head Const, and is not available.
>
> http://www.d-programming-language.org/const-faq.html#head-const
>
> It will not be added as it doesn't provide any guarantees about the code that is useful
> to the compiler. It can't be added to the existing system without complicating the type
> system even more, which outweighs the benefits.
<snip>

Guarantees about the code don't need to be useful to the compiler - they can be just useful to the programmer.  After all, this is the main point of DbC.

And it doesn't need to be a full-fledged head const.  At the simplest, a single-assignment variable could just be an rvalue - something of which the address cannot be taken and so the absence of head const becomes irrelevant.

That said, it isn't much complexity to allow the address to be taken of such a thing

    final T data;
    auto ptr = &data;

with the following rules:
- if T is a value type, immutable(something)[] or immutable(something)*, then &data is an immutable(T)*
- otherwise, &data is a const(T)*.

Once upon a time there was const/final/invariant.  What exactly did final do back then?

Stewart.

On 12/01/2011 12:08 AM, Stewart Gordon wrote:
> On 21/11/2011 20:06, Jesse Phillips wrote:
>> What you are describing is Head Const, and is not available.
>>
>> http://www.d-programming-language.org/const-faq.html#head-const
>>
>> It will not be added as it doesn't provide any guarantees about the
>> code that is useful
>> to the compiler.  It can't be added to the existing system without
>> complicating the type
>> system even more, which outweighs the benefits.
> <snip>
>
> Guarantees about the code don't need to be useful to the compiler - they
> can be just useful to the programmer. After all, this is the main point
> of DbC.
>
> And it doesn't need to be a full-fledged head const. At the simplest, a
> single-assignment variable could just be an rvalue - something of which
> the address cannot be taken and so the absence of head const becomes
> irrelevant.
>
> That said, it isn't much complexity to allow the address to be taken of
> such a thing
>
> final T data;
> auto ptr = &data;
>
> with the following rules:
> - if T is a value type, immutable(something)[] or immutable(something)*,
> then &data is an immutable(T)*
> - otherwise, &data is a const(T)*.
>
> Once upon a time there was const/final/invariant. What exactly did final
> do back then?
>
> Stewart.

Here is some documentation from that time:
http://www.digitalmars.com/d/final-const-invariant.html

It did indeed mean head const, like in Java. I wonder why it was removed from the design though, it gives extra expressiveness at no cost. (maybe because then people will start pushing for readonly (tail const)? :))