On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
> I assumed that it knows - when is trying to instatiate s.value template - that "s.value" is part of an assignment and that it will be assigned to an int.

This is somewhat wrong part. "s.value" is distinct separate expression that must be evaluated by compiler on its own before proceeding. The fact that it is later used in assignment expression is not know at that moment. One can define some analysis rules that will make it do so but it is a very major change to compiler internals.

On Friday, 22 November 2013 at 13:43:59 UTC, Jonathan M Davis wrote:
> On Friday, November 22, 2013 14:29:46 Timon Gehr wrote:
>> The request would be reasonable if 'value' was declared as follows though:
>> 
>> @property T value(T)() if (is(T == int)) { return _intValue; }
>> 
>> i.e. the fact that the template argument equals the type of the
>> resulting call can be read off directly from the signature. This is in
>> the same ballpark as the existing IFTI features.
>
> How so? IFTI works by inferring the template arguments from the function
> arguments. In this case, for the compiler to figure out a type that it could
> use to instantiate the template, it would have to disect the template
> constraint, which is compeletly different. Yes, this particular template
> constraint is very simplistic, but the compiler doesn't even look at the
> template constraint until it has a type to test with it, and in most cases, it
> would have no way of inferring what types might work even if it did look.
>
> Trying to get the compiler to infer T for value would be a drastic change to
> how it deals with templates, and at best, it would be able to figure out what
> to do in only the most simplistic of cases. In fact, the only cases that it
> could figure it out would very simplistic cases where there was only one
> possible answer, and if there's only one type that will work with a template,
> then there really wasn't much point in templatizing it in the first place. And
> as soon as there are multiple types which could work with a template, the
> compiler couldn't figure out the correct type no matter how smart it was,
> because it would need a way of choosing which of the options to take. e.g.
>
> template foo(T)
>      if(is(T == int) || is(T == byte))
> {
>     ...
> }
>
> Should foo be instantiated with int or byte? Both are equally valid.
>
> The OP has come up with a contrived example where it seems obvious to him what
> type the compiler should use to instantiate a template which has been given no
> template arguments and no function arguments to infer the template arguments
> from. But the compiler has no plumbing for figuring out such a thing, and
> adding such plumbing would be pointless, because it would only work in
> contrived cases such as this one where there was no point in templatizing the
> function in the first place.
>
> - Jonathan M Davis

Timon was right, I mean T as return type.

Too bad it needs a drastic change :\

On 11/22/2013 02:50 PM, Dicebot wrote:
> On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
>> I assumed that it knows - when is trying to instatiate s.value
>> template - that "s.value" is part of an assignment and that it will be
>> assigned to an int.
>
> This is somewhat wrong part. "s.value" is distinct separate expression
> that must be evaluated by compiler on its own before proceeding. The
> fact that it is later used in assignment expression is not know at that
> moment.

Lambda parameter type deduction needs to know this too.

> One can define some analysis rules that will make it do so but
> it is a very major change to compiler internals.

Do you know the relevant compiler internals? I cannot really imagine it being a major change. (It wouldn't be in the D frontend I am currently developing as a side project.)

On 11/22/2013 02:43 PM, Jonathan M Davis wrote:
> On Friday, November 22, 2013 14:29:46 Timon Gehr wrote:
>> >The request would be reasonable if 'value' was declared as follows though:
>> >
>> >@property T value(T)() if (is(T == int)) { return _intValue; }
>> >
>> >i.e. the fact that the template argument equals the type of the
>> >resulting call can be read off directly from the signature. This is in
>> >the same ballpark as the existing IFTI features.
> How so? IFTI works by inferring the template arguments from the function
> arguments. In this case, for the compiler to figure out a type that it could
> use to instantiate the template, it would have to disect the template
> constraint, which is compeletly different. Yes, this particular template
> constraint  ...

I am not talking about the template constraint at all. The following would still be a signature that would work:

@property T value(T)(){ return _intValue; }

On Friday, November 22, 2013 14:29:46 Timon Gehr wrote:
> On 11/22/2013 01:29 PM, Jonathan M Davis wrote:
> > On Friday, November 22, 2013 11:50:57 Andrea Fontana wrote:
> >> I just mean:
> >> 
> >> int t = s.value;  // Means  int t = s.value!int;
> >> 
> >> If there's a problem with template instantiatio is the same we
> >> have now.
> >> Now I have to write:
> >> 
> >> int t = s.value!int;
> >> 
> >> so if there's a problem with !int, it's just like now.
> >> 
> >> It's just a syntactic sugar, no new feature... Am I wrong?
> > 
> > Again, how is the compiler supposed to have any clue that you want to instantiate value with int in the case of
> > 
> > int t = s.value;
> > 
> > The left-hand side of the expression has no impact on the type of the right- hand side,
> 
> If you mean the type of the variable declaration, then yes it does.
> 
> int delegate(int) dg1 = x=>x;
> float delegate(float) dg2 = x=>x;
> 
> static assert(!is(typeof(x=>x)));

There are a few cases where the compiler does that but not many. In general, the right-hand side of an assignment is evaluated separately from the left and thus gets no type information from the left-hand side. But even if it did, in this case, that would mean determining the template argument from the return type, which is completely backwards to how template instantiation works, and attempting that would be a lot like attempting to overload on the return type of a function, which completely goes against how C-based languages work.

- Jonathan M Davis

On Friday, November 22, 2013 15:20:30 Timon Gehr wrote:
> On 11/22/2013 02:50 PM, Dicebot wrote:
> > On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
> >> I assumed that it knows - when is trying to instatiate s.value template - that "s.value" is part of an assignment and that it will be assigned to an int.
> > 
> > This is somewhat wrong part. "s.value" is distinct separate expression that must be evaluated by compiler on its own before proceeding. The fact that it is later used in assignment expression is not know at that moment.
> 
> Lambda parameter type deduction needs to know this too.

I believe that the only cases where the compiler uses the left-hand side of of an assignment or initialization to determine anything about the type of the right-hand side is when the right-hand side is a literal (be it a lambda literal, array literal, or some other kind of literal).

- Jonathan M Davis

On 11/22/2013 04:14 PM, Jonathan M Davis wrote:
> On Friday, November 22, 2013 15:20:30 Timon Gehr wrote:
>> On 11/22/2013 02:50 PM, Dicebot wrote:
>>> On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
>>>> I assumed that it knows - when is trying to instatiate s.value
>>>> template - that "s.value" is part of an assignment and that it will be
>>>> assigned to an int.
>>>
>>> This is somewhat wrong part. "s.value" is distinct separate expression
>>> that must be evaluated by compiler on its own before proceeding. The
>>> fact that it is later used in assignment expression is not know at that
>>> moment.
>>
>> Lambda parameter type deduction needs to know this too.
>
> I believe that the only cases where the compiler uses the left-hand side of of
> an assignment or initialization to determine anything about the type of the
> right-hand side is when the right-hand side is a literal (be it a lambda
> literal, array literal, or some other kind of literal).
>
> - Jonathan M Davis
>


int delegate(int) dg = b?x=>x:x=>2*x;

On Friday, November 22, 2013 16:21:43 Timon Gehr wrote:
> On 11/22/2013 04:14 PM, Jonathan M Davis wrote:
> > On Friday, November 22, 2013 15:20:30 Timon Gehr wrote:
> >> On 11/22/2013 02:50 PM, Dicebot wrote:
> >>> On Friday, 22 November 2013 at 13:43:49 UTC, Andrea Fontana wrote:
> >>>> I assumed that it knows - when is trying to instatiate s.value template - that "s.value" is part of an assignment and that it will be assigned to an int.
> >>> 
> >>> This is somewhat wrong part. "s.value" is distinct separate expression that must be evaluated by compiler on its own before proceeding. The fact that it is later used in assignment expression is not know at that moment.
> >> 
> >> Lambda parameter type deduction needs to know this too.
> > 
> > I believe that the only cases where the compiler uses the left-hand side of of an assignment or initialization to determine anything about the type of the right-hand side is when the right-hand side is a literal (be it a lambda literal, array literal, or some other kind of literal).
> > 
> > - Jonathan M Davis
> 
> int delegate(int) dg = b?x=>x:x=>2*x;

Yeah. The result of the right-hand side is a lambda literal.

- Jonathan M Davis

On 11/22/2013 07:14 AM, Jonathan M Davis wrote:

> I believe that the only cases where the compiler uses the left-hand side of of
> an assignment or initialization to determine anything about the type of the
> right-hand side is when the right-hand side is a literal (be it a lambda
> literal, array literal, or some other kind of literal).

Any implicit conversion needs that too, e.g. alias this.

struct S
{
    double d;

    alias d this;
}

void main()
{
    auto s = S();
    double d = s;
}

The example will be more impressive when multiple 'alias this' is supported.

Ali