That is actually a good point.

On Thu, 2013-02-07 at 22:55 +0100, Jonathan M Davis wrote:
> Except that mixins are generally unacceptable in APIs, because they
> don't end
> up in the documentation. That means that this works only if you don't
> care
> about documentation. So, it's almost useless. Putting @property on
> there also
> looks better but isn't that big a deal. However, the lack of
> documentation
> _is_ a big deal.

On Thursday, 7 February 2013 at 21:55:12 UTC, Jonathan M Davis wrote:
> Except that mixins are generally unacceptable in APIs, because they don't end
> up in the documentation. That means that this works only if you don't care
> about documentation. So, it's almost useless. Putting @property on there also
> looks better but isn't that big a deal. However, the lack of documentation
> _is_ a big deal.
>

Again, why would you need to @property for the case of a read/write pattern.
Just make it public:

struct S {
  // Best int ever
  int i;
},
then switch to this as needed:
struct S {
  < accessors >

  // Best int ever
  int _i;
}
when needed.

This way you have documentation still in tact. If you want read accessor only from the start, go with:

struct S {
  mixin ReadOnly!_i;
  // Best int ever
  int _i;
}

I can understand documenting a member - quite important. But documentation on a generated accessor is not necessary. And if you customize it you can document it.

No extra feature needed.

Thanks
Dan

On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
> <jmdavisProg@gmx.com> wrote:
>
>
>> struct S
>> {
>> @property int i;
>> }
>
> struct S
> {
> mixin(boilerplateProperty("i"));
> }
>
> I don't see this as a difficult problem to solve.
>
> -Steve

I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity.

Andrei

On 2/7/13 4:55 PM, Jonathan M Davis wrote:
> On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
>> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis<jmdavisProg@gmx.com>
>>
>> wrote:
>>> struct S
>>> {
>>>
>>> @property int i;
>>>
>>> }
>>
>> struct S
>> {
>> mixin(boilerplateProperty("i"));
>> }
>>
>> I don't see this as a difficult problem to solve.
>
> Except that mixins are generally unacceptable in APIs, because they don't end
> up in the documentation. That means that this works only if you don't care
> about documentation. So, it's almost useless. Putting @property on there also
> looks better but isn't that big a deal. However, the lack of documentation
> _is_ a big deal.

Well there's the version(DDoc) ... etc. possibility.

Andrei

On Thu, 07 Feb 2013 16:55:01 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Thursday, February 07, 2013 16:12:34 Steven Schveighoffer wrote:
>> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis <jmdavisProg@gmx.com>
>>
>> wrote:
>> > struct S
>> > {
>> >
>> > @property int i;
>> >
>> > }
>>
>> struct S
>> {
>> mixin(boilerplateProperty("i"));
>> }
>>
>> I don't see this as a difficult problem to solve.
>
> Except that mixins are generally unacceptable in APIs, because they don't end
> up in the documentation. That means that this works only if you don't care
> about documentation. So, it's almost useless. Putting @property on there also
> looks better but isn't that big a deal. However, the lack of documentation
> _is_ a big deal.

True.  But we can fix that just as easily (will ddoc currently parse mixin-generated docs?  If not it should).

-Steve

On Thu, 07 Feb 2013 17:25:16 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
>> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
>> <jmdavisProg@gmx.com> wrote:
>>
>>
>>> struct S
>>> {
>>> @property int i;
>>> }
>>
>> struct S
>> {
>> mixin(boilerplateProperty("i"));
>> }
>>
>> I don't see this as a difficult problem to solve.
>>
>> -Steve
>
> I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity.

My syntax highlighter highlights string and writeln, even though they aren't language builtins.  If we establish a standard mixin template, certainly editors can be made to highlight such a mixin, along with providing the expected code completion.

-Steve

On Thursday, February 07, 2013 22:19:53 Dan wrote:
> On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
> > You missed the point. When this gets lowered to accessor
> > functions and a
> > private variable, you ensure that you can later on add your
> > magic soup,
> > without breaking code that relied on i being a real field.
> > (E.g. taking
> > the address, using +=, -=, ...)
> 
> Quite likely I missed the point.
> Today I have:
> struct S
> {
> @property int i;
> }
> 
> 
> Tomorrow I decide I need to track every time int i is read and
> written.
> How is that done?
> I assume that that sort of encapsulation is what we are after.

You rewrite it as explicit property functions. No code breaks, because it was really property functions all along. You just didn't have to type them.

- Jonathan M Davis

On Thursday, 7 February 2013 at 13:56:17 UTC, Steven Schveighoffer wrote:
> On Wed, 06 Feb 2013 21:53:25 -0500, deadalnix <deadalnix@gmail.com> wrote:
>
>> On Wednesday, 6 February 2013 at 21:30:10 UTC, Timon Gehr wrote:
>>>> &(fun, fun)
>>>>
>>>
>>> Agh, comma strikes again. It should be handled analogous to the ternary expression. i.e. the expression above evaluates fun and then returns the function pointer. The DIP now states this. (the second fun is in address-taken position.) This is in agreement to how lvalue positions propagate into comma expressions.
>>>
>>
>> Adding more special cases are not gonna create a good DIP.
>
> I don't they are so much a special case, as they are a clarification.
>
> The two "exceptions" are simply explaining that because ternary operator and comma operators evaluate to an lvalue, it is equivalent to putting the & on the resulting lvalue.
>

You have the following behavior :
 - & take the address of what is before.
 - foo is call to function foo.
 - special case : &foo is the first class function foo. (here expression foo have a new meaning).
 - In a comma expression, if the last item is a function, it is evaluated, unless the comma expression is in an address of context, in which case the function pointer is returned.
 - Same goes for ternary, except that both branches are evaluated in that context.

This is exactly how special case (3) turtle down to definition of many other languages constructs. For instance,

int a;
int foo() { return a }

static assert(is(typeof(foo) == typeof(a))); // Pass
condition ? foo : a; // OK.
&(condition ? foo : a); // Type error between foo of unexpressible type (static array of instructions) and a of type int.

On Friday, 8 February 2013 at 04:06:40 UTC, Jonathan M Davis wrote:
> On Thursday, February 07, 2013 22:19:53 Dan wrote:
>> On Thursday, 7 February 2013 at 21:05:49 UTC, Robert wrote:
>> > You missed the point. When this gets lowered to accessor
>> > functions and a
>> > private variable, you ensure that you can later on add your
>> > magic soup,
>> > without breaking code that relied on i being a real field.
>> > (E.g. taking
>> > the address, using +=, -=, ...)
>> 
>> Quite likely I missed the point.
>> Today I have:
>> struct S
>> {
>> @property int i;
>> }
>> 
>> 
>> Tomorrow I decide I need to track every time int i is read and
>> written.
>> How is that done?
>> I assume that that sort of encapsulation is what we are after.
>
> You rewrite it as explicit property functions. No code breaks, because it was
> really property functions all along. You just didn't have to type them.
>

That seems to me like one of the best proposed idea in many thread happening on the subject.

On Friday, 8 February 2013 at 00:33:47 UTC, Steven Schveighoffer wrote:
> On Thu, 07 Feb 2013 17:25:16 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/7/13 4:12 PM, Steven Schveighoffer wrote:
>>> On Thu, 07 Feb 2013 15:25:57 -0500, Jonathan M Davis
>>> <jmdavisProg@gmx.com> wrote:
>>>
>>>
>>>> struct S
>>>> {
>>>> @property int i;
>>>> }
>>>
>>> struct S
>>> {
>>> mixin(boilerplateProperty("i"));
>>> }
>>>
>>> I don't see this as a difficult problem to solve.
>>>
>>> -Steve
>>
>> I like that, too, with the note that various syntax highlighters etc. won't be able to see much about that entity.
>
> My syntax highlighter highlights string and writeln, even though they aren't language builtins.  If we establish a standard mixin template, certainly editors can be made to highlight such a mixin, along with providing the expected code completion.
>

Most does it when using the q string syntax.