View mode: basic / threaded / horizontal-split · Log in · Help
April 12, 2013
Template parameter deduction for constructors?
This is one of the few C++14 core language proposals that seem 
interesting for D:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html

The purpose of this idea is to avoid the helper functions that 
are currently used in D to build template structs/classes. Even 
if this feature is restricted to only a subset of all the 
templated structs/classes it seems useful to avoid some 
boilerplate code.

Is this idea adaptable to D?

Bye,
bearophile
April 13, 2013
Re: Template parameter deduction for constructors?
On 04/12/2013 04:00 PM, bearophile wrote:

> This is one of the few C++14 core language proposals that seem
> interesting for D:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
>
> The purpose of this idea is to avoid the helper functions that are
> currently used in D to build template structs/classes. Even if this
> feature is restricted to only a subset of all the templated
> structs/classes it seems useful to avoid some boilerplate code.
>
> Is this idea adaptable to D?
>
> Bye,
> bearophile

This has come up multiple times before, most recently on the D.learn 
forum. My reaction is that what if the constructor is also a template? 
Or what if only the constructor is a template?

To paraphrase Steven Schveighoffer:

- if only the type is a template then the constructor parameters are 
used for deducing the template parameters of the type

- if only the constructor is a template, then the constructor parameters 
are used for deducing the template parameters of the constructor

- if both are templates then it is an ambiguity

I still think that the code will be confusing. If the proposal is 
implemented, the two lines in main below will look the same but will 
have different meanings:

import std.stdio;

// Today:
struct S
{
    this(T)(T param)
    {
        writefln("constructing with %s", T.stringof);
    }
}

// Proposed:
struct S2(T)
{
    this(T param)
    {
        writefln("constructing S2!%s", T.stringof);
    }
}

void main()
{
    /* Can we tell by reading the following code whether S or S2 is a
     * template, or whether the constructor of one of them is a
     * template? Do we care? */
    auto s = S(42);
    auto s2 = S2(43); // This is proposed; not valid yet.
}

Note that the C++ proposal does not touch on this point.

Ali
April 13, 2013
Re: Template parameter deduction for constructors?
On Friday, 12 April 2013 at 23:00:20 UTC, bearophile wrote:
> The purpose of this idea is to avoid the helper functions that 
> are currently used in D to build template structs/classes. Even 
> if this feature is restricted to only a subset of all the 
> templated structs/classes it seems useful to avoid some 
> boilerplate code.

This just seems like a bandaid solution to the problem. If it 
works in this case then beginners will think it works in every 
case, and will be even more confused when it stops working.

Simple with minor inconvenience is better than complex in my 
opinion.
April 13, 2013
Re: Template parameter deduction for constructors?
On Saturday, 13 April 2013 at 08:40:15 UTC, Peter Alexander wrote:
> This just seems like a bandaid solution to the problem. If it 
> works in this case then beginners will think it works in every 
> case, and will be even more confused when it stops working.

When would it stop working? You might want to add any such 
example to http://d.puremagic.com/issues/show_bug.cgi?id=6082.

> Simple with minor inconvenience is better than complex in my 
> opinion.

The complexity is already there, in the form of (free) ITFI 
functions.

David
April 14, 2013
Re: Template parameter deduction for constructors?
On Saturday, 13 April 2013 at 15:52:01 UTC, David Nadlinger wrote:
> On Saturday, 13 April 2013 at 08:40:15 UTC, Peter Alexander 
> wrote:
>> This just seems like a bandaid solution to the problem. If it 
>> works in this case then beginners will think it works in every 
>> case, and will be even more confused when it stops working.
>
> When would it stop working? You might want to add any such 
> example to http://d.puremagic.com/issues/show_bug.cgi?id=6082.

Something like this:

struct Foo(T)
{
    static if (is(T == int))
        this(string x) {}
    else
        this(T x) {}
}

T is ambiguous for Foo("bar")


Also this:

struct Foo(T)
{
    this(T x) {}
    this(int x) {}
}

Calls to Foo(x) are ambiguous when is(typeof(x) : int).

Allowing deduction in this case would be frustrating. Imagine 
having a struct where this worked, and then you wanted to add a 
new constructor, or maybe just modify the constructor for one 
instantiation. You would then have to change all calls to 
explicitly specify parameters.


> The complexity is already there, in the form of (free) ITFI 
> functions.

Unfortunately you are right because of the eponymous template 
hack. Without it, normal functions are non-complex.

void foo(T)(T x) {}
void foo(string x) {}

Here, foo("bar") is unambiguously the second call. (D compilers 
don't allow template/non-template overloads at the moment due to 
a bug, but this should work).

Unfortunately the eponymous hack falls down quite easily. For 
example, IFTI on this function fails:

template foo(T)
{
    static if (true)
        void foo(T)(T x) {}
}

So it is just as fragile as this proposal.
April 14, 2013
Re: Template parameter deduction for constructors?
On 04/13/2013 01:00 AM, bearophile wrote:
> This is one of the few C++14 core language proposals that seem
> interesting for D:
>
> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
>
> The purpose of this idea is to avoid the helper functions that are
> currently used in D to build template structs/classes. Even if this
> feature is restricted to only a subset of all the templated
> structs/classes it seems useful to avoid some boilerplate code.
>
> Is this idea adaptable to D?
>
> Bye,
> bearophile

I think the differences to be accounted for are basically that D has 
n-ary default constructors, static opCall, and static if. Furthermore, 
with IFTI, it is possible to only specify the prefix of the template 
arguments.

---

struct S(T...){
    T data;
}

S(1,2,3); // ?
S!double(1,2,3); // ?

---

struct S(T...){
    T data;
    static if(T.length){
        this(T x){ }
    }
}

S(1,2,3); // ?

---

struct S(T...){
    static opCall(T)(T args){ }
}

S(1,2,3); // ?

---
April 15, 2013
Re: Template parameter deduction for constructors?
On Fri, 12 Apr 2013 20:00:58 -0400, Ali Çehreli <acehreli@yahoo.com> wrote:

> On 04/12/2013 04:00 PM, bearophile wrote:
>
>  > This is one of the few C++14 core language proposals that seem
>  > interesting for D:
>  >
>  > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
>  >
>  > The purpose of this idea is to avoid the helper functions that are
>  > currently used in D to build template structs/classes. Even if this
>  > feature is restricted to only a subset of all the templated
>  > structs/classes it seems useful to avoid some boilerplate code.
>  >
>  > Is this idea adaptable to D?
>  >
>  > Bye,
>  > bearophile
>
> This has come up multiple times before, most recently on the D.learn  
> forum. My reaction is that what if the constructor is also a template?  
> Or what if only the constructor is a template?
>
> To paraphrase Steven Schveighoffer:
>
> - if only the type is a template then the constructor parameters are  
> used for deducing the template parameters of the type
>
> - if only the constructor is a template, then the constructor parameters  
> are used for deducing the template parameters of the constructor
>
> - if both are templates then it is an ambiguity

In other words, if both are templates, it requires what is done today  
(specifically instantiating the class/struct template, then you can use  
IFTI on the constructor).  This is not terrible.

> I still think that the code will be confusing. If the proposal is  
> implemented, the two lines in main below will look the same but will  
> have different meanings:
>
> import std.stdio;
>
> // Today:
> struct S
> {
>      this(T)(T param)
>      {
>          writefln("constructing with %s", T.stringof);
>      }
> }
>
> // Proposed:
> struct S2(T)
> {
>      this(T param)
>      {
>          writefln("constructing S2!%s", T.stringof);
>      }
> }
>
> void main()
> {
>      /* Can we tell by reading the following code whether S or S2 is a
>       * template, or whether the constructor of one of them is a
>       * template? Do we care? */
>      auto s = S(42);
>      auto s2 = S2(43); // This is proposed; not valid yet.
> }
>
> Note that the C++ proposal does not touch on this point.

I don't think this is confusing any more than standard IFTI or automatic  
type deduction is confusing.

-Steve
April 15, 2013
Re: Template parameter deduction for constructors?
On Sun, 14 Apr 2013 10:29:11 -0400, Peter Alexander  
<peter.alexander.au@gmail.com> wrote:

> On Saturday, 13 April 2013 at 15:52:01 UTC, David Nadlinger wrote:
>> On Saturday, 13 April 2013 at 08:40:15 UTC, Peter Alexander wrote:
>>> This just seems like a bandaid solution to the problem. If it works in  
>>> this case then beginners will think it works in every case, and will  
>>> be even more confused when it stops working.
>>
>> When would it stop working? You might want to add any such example to  
>> http://d.puremagic.com/issues/show_bug.cgi?id=6082.
>
> Something like this:
>
> struct Foo(T)
> {
>      static if (is(T == int))
>          this(string x) {}
>      else
>          this(T x) {}
> }
>
> T is ambiguous for Foo("bar")

template Foo(T)
{
   static if(is(T == int))
       Foo(string x) {}
   else
       Foo(T x) {}
}

This is the equivalent function.  It correctly requires explicit  
instantiation, and cannot involve IFTI.

>
>
> Also this:
>
> struct Foo(T)
> {
>      this(T x) {}
>      this(int x) {}
> }
>
> Calls to Foo(x) are ambiguous when is(typeof(x) : int).

Foo!int is not ambiguous, it's illegal.

Technically, a valid implementation would be:

struct Foo(T)
{
   this(T x) {}
   static if(is(T != int))
      this(int x) {}
}

Which I think should instantiate just fine, but I don't know.

> Allowing deduction in this case would be frustrating. Imagine having a  
> struct where this worked, and then you wanted to add a new constructor,  
> or maybe just modify the constructor for one instantiation. You would  
> then have to change all calls to explicitly specify parameters.

This is due to issues with the compiler.  It currently requires a specific  
form to use IFTI, this would necessarily need to change.  If the  
constructor is ambiguous or did not involve the template type (such as  
your int x argument above), then you would have to explicitly instantiate,  
necessarily.

But you should be allowed to do something like this:

struct S(T)
{
   this(T t) {}
   this(T t, string s) {}
}

>> The complexity is already there, in the form of (free) ITFI functions.
>
> Unfortunately you are right because of the eponymous template hack.  
> Without it, normal functions are non-complex.
>
> void foo(T)(T x) {}
> void foo(string x) {}
>
> Here, foo("bar") is unambiguously the second call. (D compilers don't  
> allow template/non-template overloads at the moment due to a bug, but  
> this should work).

This is not the same as a template struct with multiple constructors.  It  
is like having two structs, one which is templated, one which is not.   
Given that the above currently doesn't work, I don't know what should  
happen with multiple structs, but I think it should be consistent with  
correct overloaded function behavior.

>
> Unfortunately the eponymous hack falls down quite easily. For example,  
> IFTI on this function fails:
>
> template foo(T)
> {
>      static if (true)
>          void foo(T)(T x) {}
> }
>
> So it is just as fragile as this proposal.

That is an issue with IFTI, not the proposal.  Any enhancements with IFTI  
should translate to this as well.

I think your concerns are a bit exaggerated.  This is something that is  
more than annoying for the cases where there is one constructor, and by  
default falls back on current behavior.  We are adding to the current  
behavior, not breaking it, any perceived incorrect behavior is not any  
more confusing that the current IFTI rules.

-Steve
April 15, 2013
Re: Template parameter deduction for constructors?
On Sun, 14 Apr 2013 11:47:47 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/13/2013 01:00 AM, bearophile wrote:
>> This is one of the few C++14 core language proposals that seem
>> interesting for D:
>>
>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
>>
>> The purpose of this idea is to avoid the helper functions that are
>> currently used in D to build template structs/classes. Even if this
>> feature is restricted to only a subset of all the templated
>> structs/classes it seems useful to avoid some boilerplate code.
>>
>> Is this idea adaptable to D?
>>
>> Bye,
>> bearophile
>
> I think the differences to be accounted for are basically that D has  
> n-ary default constructors, static opCall, and static if. Furthermore,  
> with IFTI, it is possible to only specify the prefix of the template  
> arguments.
>
> ---
>
> struct S(T...){
>      T data;
> }
>
> S(1,2,3); // ?

Should work.  The implicit default constructor should be treated as a  
function.

> S!double(1,2,3); // ?

Should work with T == {double, int, int}

>
> ---
>
> struct S(T...){
>      T data;
>      static if(T.length){
>          this(T x){ }
>      }
> }
>
> S(1,2,3); // ?

I think this should follow IFTI rules.  If this is allowed:

template foo(T...) {
   static if(T.length)
      void foo(T x) {}
}

Then the struct should be allowed as well.

>
> ---
>
> struct S(T...){
>      static opCall(T)(T args){ }
> }
>
> S(1,2,3); // ?

I would say it should work.

-Steve
April 15, 2013
Re: Template parameter deduction for constructors?
On 04/15/2013 05:18 PM, Steven Schveighoffer wrote:
> On Sun, 14 Apr 2013 11:47:47 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 04/13/2013 01:00 AM, bearophile wrote:
>>> This is one of the few C++14 core language proposals that seem
>>> interesting for D:
>>>
>>> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html
>>>
>>> The purpose of this idea is to avoid the helper functions that are
>>> currently used in D to build template structs/classes. Even if this
>>> feature is restricted to only a subset of all the templated
>>> structs/classes it seems useful to avoid some boilerplate code.
>>>
>>> Is this idea adaptable to D?
>>>
>>> Bye,
>>> bearophile
>>
>> I think the differences to be accounted for are basically that D has
>> n-ary default constructors, static opCall, and static if. Furthermore,
>> with IFTI, it is possible to only specify the prefix of the template
>> arguments.
>>
>> ---
>>
>> struct S(T...){
>>      T data;
>> }
>>
>> S(1,2,3); // ?
>
> Should work.  The implicit default constructor should be treated as a
> function.
>

It cannot be treated exactly like a function because it depends on the 
struct layout. It is very well possible that the struct layout cannot be 
easily determined without instantiation. The example below demonstrates 
that it is not entirely obvious.

>>...
>>
>> ---
>>
>> struct S(T...){
>>      T data;
>>      static if(T.length){
>>          this(T x){ }
>>      }
>> }
>>
>> S(1,2,3); // ?
>
> I think this should follow IFTI rules.  If this is allowed:
>
> template foo(T...) {
>     static if(T.length)
>        void foo(T x) {}
> }

This probably shouldn't be allowed because a compiler cannot satisfy 
arbitrary expressions.

>
> Then the struct should be allowed as well.
>

It is more subtle than that. The layout of S begins with T data. Does 
this mean S(1,2,3) instantiates to S!(int,int,int)(1,2,3), as above ? 
When does this happen? Is it checked that the constructor used for 
guessing the parameters is the constructor that gets called?

Also: What happens if there is more than one constructor?

> ...
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home