On 2013-01-30 00:55, Rob T wrote:

> Given how D currently works, I don't see how we can realistically
> implement a function as a drop in replacement for a variable and expect
> code to continue working as if nothing had changed.
>
> One of the bigger problems is that the getter returns by value, not ref,
> so everything that expects a ref return will fail.
>
> I expect to make precise variable emulation through properties will
> require a lot of compiler magic, and there will be inevitable bugs and
> conflicts that follow. I really don't see that there's enough value with
> the property concept to justify the costs of precise variable emulation.
>
> You know a lot more about implementing compiler magic than I do, so I'll
> ask you if you think the effort is doable enough to justify having
> property functions that can act like a drop in replacement for existing
> variables?

Implement this:

struct Foo
{
    @property int a;
}

Lowered to:

struct Foo
{
    private int a_;
    @property int a () { return a_; }
    @property int a (int value) { return a_ = value; }
}

-- 
/Jacob Carlborg

On 2013-01-30 02:40, TommiT wrote:

> I always thought that having public member variables is a bad style of
> programming because of the lack of encapsulation. So, if there's a
> language feature that enables you to write public member variables, and
> later on, replace them with property functions, wouldn't that mean that
> the language is encouraging this particular kind of bad style of
> programming?

I really don't see much point in properties/methods that just forwards to an instance variable.

-- 
/Jacob Carlborg

On 2013-01-30 03:15, Rob T wrote:

> Even with @property restrictions, I still don't think it will work as
> expected. For example, if the variable is a struct, then you have to
> disallow operations on the struct from outside.
>
> Example:
>
> struct Y { int a; }
>
> struct X{ @property Y y; }
>
> X x;
>
> x.y.a = 4; // <- this has to be illegal!
>
> Reason?
>
> struct X{
>
>    Y _y;
>
>    @property Y y{ return _y; }
>
> }
>
> // this won't change _y as it did before.
> x.y.a = 4;

That would require some property rewrite by the compiler.

-- 
/Jacob Carlborg

On 1/30/13 10:10 AM, Jacob Carlborg wrote:
> On 2013-01-30 02:40, TommiT wrote:
>
>> I always thought that having public member variables is a bad style of
>> programming because of the lack of encapsulation. So, if there's a
>> language feature that enables you to write public member variables, and
>> later on, replace them with property functions, wouldn't that mean that
>> the language is encouraging this particular kind of bad style of
>> programming?
>
> I really don't see much point in properties/methods that just forwards
> to an instance variable.

Insurance.

Andrei

On Wednesday, 30 January 2013 at 15:10:37 UTC, Jacob Carlborg wrote:
> I really don't see much point in properties/methods that just forwards to an instance variable.

I assume you mean something like this:

struct S
{
    private T _t;

    ref T get() { return _t; }

    void set(T t) { ... }
}

The benefit of the above type of coding versus having a public T variable, is that you can change the implementation of S without changing S's interface. Perhaps I would like to change it to this (or whatever):

private static T[5] tees;

struct S
{
    private byte _idx;

    ref T get() { return tees[_idx]; }

    void set(T t) { ... }
}

On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
> ...  C# manages it ...

Nope.

On Wednesday, January 30, 2013 18:54:20 Timon Gehr wrote:
> On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
> > ... C# manages it ...
> 
> Nope.

It was my understanding that it did. Everything that I've read on it indicated that it did. But I have used C# minimally (and not recently), so I could easily be wrong when it comes to much of anything about C#.

- Jonathan M Davis

On 01/30/2013 08:44 PM, Jonathan M Davis wrote:
> On Wednesday, January 30, 2013 18:54:20 Timon Gehr wrote:
>> On 01/30/2013 03:29 AM, Jonathan M Davis wrote:
>>> ... C# manages it ...
>>
>> Nope.
>
> It was my understanding that it did. Everything that I've read on it indicated
> that it did. But I have used C# minimally (and not recently), so I could
> easily be wrong when it comes to much of anything about C#.
>
> - Jonathan M Davis
>

(C# has ref parameters. Properties cannot be passed by ref, but public fields can.)

On 2013-01-30 17:26, TommiT wrote:

> I assume you mean something like this:
>
> struct S
> {
>      private T _t;
>
>      ref T get() { return _t; }
>
>      void set(T t) { ... }
> }
>
> The benefit of the above type of coding versus having a public T
> variable, is that you can change the implementation of S without
> changing S's interface. Perhaps I would like to change it to this (or
> whatever):
>
> private static T[5] tees;
>
> struct S
> {
>      private byte _idx;
>
>      ref T get() { return tees[_idx]; }
>
>      void set(T t) { ... }
> }

Sure, but I think that's what properties are for. We currently don't have that in D but I think it would be great if fields could be exchanged with methods without breaking the API.

-- 
/Jacob Carlborg

On 2013-01-30 20:44, Jonathan M Davis wrote:

> It was my understanding that it did. Everything that I've read on it indicated
> that it did. But I have used C# minimally (and not recently), so I could
> easily be wrong when it comes to much of anything about C#.

Last time I used C# it didn't have property rewrite when returning structs.

-- 
/Jacob Carlborg