On Friday, 8 February 2013 at 05:49:39 UTC, Jonathan M Davis
wrote:
On Thursday, February 07, 2013 23:15:14 Dan wrote:
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;
},
But if you do that, then code that uses S can do stuff like
take the address of I or pass it by ref. That code will then
break when you turn it into property functions later. That's
unacceptable, meaning that in almost all cases, people just
create getters and setters which do almost nothing. It's
boilerplate that we shouldn't need.
I hope I'm not missing the point; But I see a big dilemma about
the whole ref/not ref(anymore) issue. Then I begin thinking: If
you don't Mark it as part of the public API, why should it
matter? Unless it's just a storage for data (which you guarantee
to be ref), or publicly noted for DDoc, then making use of a
internal implementation is wrong (even if it isn't marked
private).
It may be similar to...
struct S {
int i;
auto front() {return i;} ///
enum empty = false; ///
void popFront() {i++;} ///
}
//original
void func(S input) {
writeln(input.i);
input.i++;
}
//turned into referring to a range
void func(R)(R input)
if (isRange!(R)) {
//Initially built/tested with struct S and works
//but forgot to update. Still works in his own code
writeln(input.i);
input.i++;
}
If on the other hand if 'i' was intended part of the API, you
can rely on it being ref-able unless there's a major change in
design.
struct S {
int i; /// iterator number, part of API
ref auto front() {return i;} ///
...
}
Also if the programmer's code gets broke they can always avoid
upgrading until later, and fix their code when they are ready for
it. Most fixes will be minor (even if they show up dozens of
times).
