www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Templates class member functions not conditional?

reply "monarch_dodra" <monarchdodra gmail.com> writes:
This is related to:
http://d.puremagic.com/issues/show_bug.cgi?id=5193

Basically:
-------
struct S
{
   const int i;
}

struct C(T)
{
     private T val;
      property void front(T value)
         {val = value;} //HERE
}

void main()
{
   C!S test;
}
--------

I wrote a generic template C(T), with a certain member function. 
I created an instance of that template with the parameter S.

Now, I'm getting a compile error at here, which would be 
understandable...
...*if* I was calling said member function.

In C++, member functions of templates are *only* compiled if they 
are ever called. This is not just an optimization, it is meant 
specifically to allow compiling a template, only if a certain 
amount of functionality is required, and the "not required" 
functionality wouldn't compile anyways.

Is this not the case for D? Or is it currently a limitation?
Can I ever expect we'll get a "conditionally compiled on 
requirement" functionality for template struct member functions.


Regarding making the above work, I found 2 solutions:

/////////////////////  1  /////////////////////
struct C(T)
{
     private T val;
     static if(isAssignable(T!T))
     {
          property void front(T value)
             {val = value;}
     }
}

This works but:
a) It looks cludgy, and cumbursome on implementation
b) If I *were* to attemp a call to front, the compile error would 
be an obscure "fucntion not found", as opposed to "can't assign"

/////////////////////  2  /////////////////////
I find this more elegant: Make the member function itself a 
template:

struct C(T)
{
     private T val;
      property void front()(T value)
         {val = value;}
}

This works, and is correctly "conditionally compiled on 
requirement". The signature is kind of kludgy, but it works... 
AND, if someone *does* attempt to make the call, then a verbose 
compile error appears.

Thoughts?
Sep 11 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:


 Is this not the case for D? Or is it currently a limitation?


In this case I think D is working as designed. All functions 
inside a template are created when you instantiate it.



 Can I ever expect we'll get a "conditionally compiled on 
 requirement" functionality for template struct member functions.


I have asked for a  templated(Arg1, Arg2, ...) that's usable for 
this purpose too, but Walter has not commented so far.



 struct C(T)
 {
     private T val;
     static if(isAssignable(T!T))
     {
          property void front(T value)
             {val = value;}
     }
 }


Probably such use of a static if (or debug, version, etc) is the 
idiomatic way to do what you want in D. It's easy to see and 
understand for the person that reads the code.



 struct C(T)
 {
     private T val;
      property void front()(T value)
         {val = value;}
 }

 This works, and is correctly "conditionally compiled on 
 requirement". The signature is kind of kludgy, but it works... 
 AND, if someone *does* attempt to make the call, then a verbose 
 compile error appears.


This doesn't look bad, just remember this doesn't work:


struct C(T) {
     private T val;
      property void front()(T value) {
         val = value;
     }
}
void main() {
     C!int ci;
     auto f = &ci.front;
     assert(ci.val == 0);
     f(1);
     assert(ci.val == 1);
}

Bye,
bearophile
Sep 11 2012
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:

 This doesn't look bad, just remember this doesn't work:


 struct C(T) {
     private T val;
      property void front()(T value) {
         val = value;
     }
 }
 void main() {
     C!int ci;
     auto f = &ci.front;
     assert(ci.val == 0);
     f(1);
     assert(ci.val == 1);
 }

 Bye,
 bearophile


True, but this does: auto f = &ci.front!();

That said, it looks horrible, and, client code should not be 
affected in such a way. So yeah, not a great solution. Plus, it 
creates a new semantic which is not very obvious.

I'll have to admit, I'm really not a fan of of such explicit 
conditional implementations. It really burdens the code, and 
forces the implementer to think about the required conditions to 
use the function, rather than let the compiler issue a failure 
when it just *does* happen fail.

I am opening an enhancement request for this.
Sep 11 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:


 and forces the implementer to think about the required 
 conditions to use the function,


I think this is usually considered a good practice in D, just 
like using template constraints.

If you look in Phobos, similar situations are handled with static 
ifs. As example see the several static if used inside MapResult() 
to disable some of its features:

https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm.d#L384


private struct MapResult(alias fun, Range)
{
     alias Unqual!Range R;
     //alias typeof(fun(.ElementType!R.init)) ElementType;
     R _input;

     static if (isBidirectionalRange!R)
     {
          property auto ref back()
         {
             return fun(_input.back);
         }

         void popBack()
         {
             _input.popBack();
         }
     }

     this(R input)
     {
         _input = input;
     }

     static if (isInfinite!R)
     {
         // Propagate infinite-ness.
         enum bool empty = false;
     }
     else
     {
          property bool empty()
         {
             return _input.empty;
         }
     }

     void popFront()
     {
         _input.popFront();
     }

      property auto ref front()
     {
         return fun(_input.front);
     }

     static if (isRandomAccessRange!R)
     {
         static if (is(typeof(_input[ulong.max])))
             private alias ulong opIndex_t;
         else
             private alias uint opIndex_t;

         auto ref opIndex(opIndex_t index)
         {
             return fun(_input[index]);
         }
     }

     static if (hasLength!R || isSomeString!R)
     {
          property auto length()
         {
             return _input.length;
         }

         alias length opDollar;
     }

     static if (hasSlicing!R)
     {
         static if (is(typeof(_input[ulong.max .. ulong.max])))
             private alias ulong opSlice_t;
         else
             private alias uint opSlice_t;

         auto opSlice(opSlice_t lowerBound, opSlice_t upperBound)
         {
             return typeof(this)(_input[lowerBound..upperBound]);
         }
     }

     static if (isForwardRange!R)
     {
          property auto save()
         {
             auto result = this;
             result._input = result._input.save;
             return result;
         }
     }
}


Bye,
bearophile
Sep 11 2012
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 13:33:08 UTC, bearophile wrote:

 monarch_dodra:


 and forces the implementer to think about the required 
 conditions to use the function,


 I think this is usually considered a good practice in D, just 
 like using template constraints.

 If you look in Phobos, similar situations are handled with 
 static ifs. As example see the several static if used inside 
 MapResult() to disable some of its features:

 [SNIP]

 Bye,
 bearophile


I'd argue it's horrible! Why should the coder bother making these 
conditional, if calling them would have failed anyways?

The fact that it is done like this in D, I'd argue, is by 
necessity, not necessarily by good practice.

IMO, being able to do this is a much better alternative:

      property auto save()
     {
         static assert(isForwardRange!R); //Optional
         auto result = this;
         result._input = result._input.save;
         return result;
     }

It is cleaner and easier on the developer. The exact line that 
fails is reported (as opposed to "member not found"). An optional 
static assert can make the reason *why* it failed be bloody 
explicit.

The last reason why this approach is superior, is because above, 
"front(T)" *does* exist, but it is implemented as "can't work", 
and calling it MUST fail. This is different from not having it 
implemented, which allows a third party to define it via UFCS. In 
that case though, it would not be enriching the interface, it 
would be hijacking it.
Sep 11 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
monarch_dodra:


 I'd argue it's horrible! Why should the coder bother making 
 these conditional, if calling them would have failed anyways?


If you see, some of those static ifs also have an else clause.

Bye,
bearophile
Sep 11 2012
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 15:35:33 UTC, bearophile wrote:

 monarch_dodra:


 I'd argue it's horrible! Why should the coder bother making 
 these conditional, if calling them would have failed anyways?


 If you see, some of those static ifs also have an else clause.

 Bye,
 bearophile


The only one I really see is for "empty", but I don't really see 
how that changes anything? That is actually the *only* valid case 
I can see where usage of a static if is legitimate.
Sep 11 2012
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:

 monarch_dodra:


 Is this not the case for D? Or is it currently a limitation?


 In this case I think D is working as designed. All functions 
 inside a template are created when you instantiate it.

 [SNIP]

 Bye,
 bearophile


Well, the functions are declared inside the template, but do they 
have to be validated and compiled?

I mean, technically, in C++, the functions are also there, just 
not compiled and validated...
Sep 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 11, 2012 15:12:57 monarch_dodra wrote:

 On Tuesday, 11 September 2012 at 11:33:05 UTC, bearophile wrote:

 monarch_dodra:

 Is this not the case for D? Or is it currently a limitation?


 
 In this case I think D is working as designed. All functions
 inside a template are created when you instantiate it.
 
 [SNIP]
 
 Bye,
 bearophile


 
 Well, the functions are declared inside the template, but do they
 have to be validated and compiled?
 
 I mean, technically, in C++, the functions are also there, just
 not compiled and validated...


Anything inside a template is not compiled unless the template is 
instantiated, but if the template is instantiated, the entire template is 
instantiated and compiled (save for static if branches which aren't followed 
or inner templates which aren't instantiated). If C++ doesn't work that way as 
well, I find that to be very bizarre. Regardless though, that's how D works.

- Jonathan M Davis
Sep 11 2012
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 15:43:56 UTC, Jonathan M Davis 
wrote:

 Anything inside a template is not compiled unless the template 
 is
 instantiated, but if the template is instantiated, the entire 
 template is
 instantiated and compiled (save for static if branches which 
 aren't followed
 or inner templates which aren't instantiated). If C++ doesn't 
 work that way as
 well, I find that to be very bizarre. Regardless though, that's 
 how D works.

 - Jonathan M Davis


TY for putting up with me :D

C++ works a certain way, and I find it very bizarre that D 
doesn't work that way either. Then again, C++ doesn't have static 
if.



At the very least, I wish we could write:
--------
struct S(T)
{
      property void front(T value)
         if(isAssignable!(T,T))
     {
         ...
     }
}
--------
That would make things less bulky and the intent much more 
streamlined with what we already have.

In this specific case, this doesn't work because "front" itself 
isn't a template, but given the encapsulating struct *is* a 
template, I think it should be made to work.

As a matter of fact, I don't see why we can't use conditional 
implementations ALL the time? Like: If some enum is defined, or 
if a certain type works or whatever.
Sep 11 2012
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 16:34:33 UTC, monarch_dodra 
wrote:

 At the very least, I wish we could write:
 --------
 struct S(T)
 {
      property void front(T value)
         if(isAssignable!(T,T))
     {
         ...
     }
 }
 --------


..Yeah... that wouldn't work would it?

That would just prevent "front" from being matched when the call 
is attempted, but since it is a non-template, it will still get 
compiled...

Wish it did work though!

Well... time to move on...
Sep 11 2012
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 10:51:35 UTC, monarch_dodra
wrote:

 [SNIP]


One of my gripes was that the static if creates a new block,
which brakes a struct/class's natural flow. The code gets
indented, the DDoc gets placed further away from the function's
name, teh condition gets placed kind of far from the function's
name etc...

However, when written like this:

struct C(T)
{
      private T val;

      // Gets front
       property T front()
      {val = value;}

      //Writes to front
      static if(isAssignable!(T,T))
       property void front(T value)
      {val = value;}
}

Then I think it reads alright.

I think I'll come to grips with this.
Sep 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 11, 2012 19:37:02 monarch_dodra wrote:

 However, when written like this:
 
 struct C(T)
 {
       private T val;
 
       // Gets front
        property T front()
       {val = value;}
 
       //Writes to front
       static if(isAssignable!(T,T))
        property void front(T value)
       {val = value;}
 }
 
 Then I think it reads alright.


Whereas I think that that hards readibility, because it hides the fact that a 
static if is used. If you're submitting code for Phobos, please do something 
like

static if(isAssignable!(T, T))  property void front(T value) {val = value;}

or

static if(isAssignable!(T,T))
     property void front(T value) { value = value; }

rather than what you have above, otherwise it will harm maintainability.

- Jonathan M Davis
Sep 11 2012
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 17:52:44 UTC, Jonathan M Davis 
wrote:

 On Tuesday, September 11, 2012 19:37:02 monarch_dodra wrote:

 However, when written like this:
 
 struct C(T)
 {
       private T val;
 
       // Gets front
        property T front()
       {val = value;}
 
       //Writes to front
       static if(isAssignable!(T,T))
        property void front(T value)
       {val = value;}
 }
 
 Then I think it reads alright.


 Whereas I think that that hards readibility, because it hides 
 the fact that a
 static if is used. If you're submitting code for Phobos, please 
 do something
 like

 static if(isAssignable!(T, T))  property void front(T value) 
 {val = value;}

 or

 static if(isAssignable!(T,T))
      property void front(T value) { value = value; }

 rather than what you have above, otherwise it will harm 
 maintainability.

 - Jonathan M Davis


Hum... Yeah, you are kind of right.

I actually am committing something, but the code is a 2 liner. 
(enforce, then assignment).

Is one of these what you are suggesting?

//One
static if(isAssignable!(T,T))  property void front(T value)
{
     enforce(someCondition)
     value = value;
}

or

//Two
static if(isAssignable!(T,T))
      property void front(T value)
{
     enforce(someCondition)
     value = value;
}

or

//Three
static if(isAssignable!(T,T))
 property void front(T value)
{
     enforce(someCondition)
     value = value;
}


(or just plain)

//Four
static if(isAssignable!(T,T))
{
      property void front(T value)
     {
         enforce(someCondition)
         value = value;
     }
}

Which do YOU think reads best in this case? That the style I'll 
use in my submit.

I like //Three because it reads like an attribute.

Of course, I have no problem submitting it with the default 
//Four if you think that is best. I'm just trying to do as best 
possible.
Sep 11 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, September 11, 2012 20:39:55 monarch_dodra wrote:

 Is one of these what you are suggesting?
 
 //One
 static if(isAssignable!(T,T))  property void front(T value)
 {
      enforce(someCondition)
      value = value;
 }
 
 or
 
 //Two
 static if(isAssignable!(T,T))
       property void front(T value)
 {
      enforce(someCondition)
      value = value;
 }
 
 or
 
 //Three
 static if(isAssignable!(T,T))
  property void front(T value)
 {
      enforce(someCondition)
      value = value;
 }
 
 
 (or just plain)
 
 //Four
 static if(isAssignable!(T,T))
 {
       property void front(T value)
      {
          enforce(someCondition)
          value = value;
      }
 }
 
 Which do YOU think reads best in this case? That the style I'll
 use in my submit.
 
 I like //Three because it reads like an attribute.
 
 Of course, I have no problem submitting it with the default
 //Four if you think that is best. I'm just trying to do as best
 possible.


I'd use either one or four. I would definitely _not_ use three, precisely 
because it's using no indentation at all. Either the signature should be one 
line, or it needs indentation.

- Jonathan M Davis
Sep 11 2012
parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Tuesday, 11 September 2012 at 21:44:50 UTC, Jonathan M Davis 
wrote:

 I'd use either one or four. I would definitely _not_ use three, 
 precisely
 because it's using no indentation at all. Either the signature 
 should be one
 line, or it needs indentation.

 - Jonathan M Davis


I decided to use the basic notation (Four). I don't think there 
is anything wrong with experimenting, just not in Phobos.

Thankyou.
Sep 11 2012