DIP23 Counter Proposal

Era Scarecrow rtcvb32 at yahoo.com
Fri Feb 8 13:38:35 PST 2013


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).


More information about the Digitalmars-d mailing list