On 07/06/13 17:10, Dicebot wrote:
> On Saturday, 6 July 2013 at 15:05:51 UTC, Artur Skawina wrote:
>> ...
> 
> It is not that simple. Consider:
> 
> void f(T)(T t)
> {
>     static if (T == Unqual!T)
>     // one function body
>     else
>     // completely different one
> }
> 
> Currently every template instance is completely independent and tied to exact type. I don't know of any tool to express "group of related types" concept in D other than built-in "inout".

This is exactly why i did mention that this is a breaking change and that "there shouldn't be much code out there that sensibly relies on the 1:1 type propagation." Do you think this would be a problem /in practice/?

Right now IFTI chooses an expensive alternative, which is rarely required. You have to do more work to "undo" the unnecessary type propagation. This is the wrong default. "auto" makes things even worse, by increasing the number of different-but-compatible types and causing them to propagate.

artur

On Saturday, 6 July 2013 at 15:38:45 UTC, Artur Skawina wrote:
> Do you think this would be a problem /in practice/?

To me it seems highly unlikely that this would break any code.

+1 from me.

On Saturday, 6 July 2013 at 15:38:45 UTC, Artur Skawina wrote:
> Do you think this would be a problem /in practice/?

Yes. Honestly, lot of problems. I can easily imagine template function that modifies its argument in-place for a mutable qualifier and allocates a copy for an immutable one. Templates that introspect their parameter type to format some string. Different algorithms for processing mutable and immutable versions of same container.

And it is not just code breakage - you propose some magic instead of simple well-defined semantics and so far I don't even see the detailed description how new system should behave. Currently template body is defined only by its parameter set, your proposal changes that as far as I understand.

I think more reasonable approach is to define "inout" in template parameter specialization to mean "I don't care what it is, make it compiler error to rely on any behavior difference between them". Don't know what to do about mangling though. Will also most likely need to prohibit and direct reference to T.

It looks like extremely complex way to solve only one minor part of general problem (template bloat).

On Saturday, 6 July 2013 at 18:07:08 UTC, Dicebot wrote:
> On Saturday, 6 July 2013 at 15:38:45 UTC, Artur Skawina wrote:
>> Do you think this would be a problem /in practice/?
>
> Yes. Honestly, lot of problems. I can easily imagine template function that modifies its argument in-place for a mutable qualifier and allocates a copy for an immutable one. Templates that introspect their parameter type to format some string. Different algorithms for processing mutable and immutable versions of same container.

He's talking about changing the semantics only on POD types, like int, struct of ints, static array of ints... only types that can implicitly convert from immutable to mutable.

> And it is not just code breakage - you propose some magic instead of simple well-defined semantics and so far I don't even see the detailed description how new system should behave.

As I understand it, it would be like what C++ does, but only for POD types. Just take const, immutable, whatever away when they're passed by value.

06-Jul-2013 22:54, TommiT пишет:
> On Saturday, 6 July 2013 at 18:07:08 UTC, Dicebot wrote:
>> On Saturday, 6 July 2013 at 15:38:45 UTC, Artur Skawina wrote:
>>> Do you think this would be a problem /in practice/?
>>
>> Yes. Honestly, lot of problems. I can easily imagine template function
>> that modifies its argument in-place for a mutable qualifier and
>> allocates a copy for an immutable one. Templates that introspect their
>> parameter type to format some string. Different algorithms for
>> processing mutable and immutable versions of same container.
>
> He's talking about changing the semantics only on POD types, like int,
> struct of ints, static array of ints... only types that can implicitly
> convert from immutable to mutable.
>

I've seen an aggressive proposal back in the day to just do a shallow unqual on all aggregates passed by value.

>> And it is not just code breakage - you propose some magic instead of
>> simple well-defined semantics and so far I don't even see the detailed
>> description how new system should behave.
>
> As I understand it, it would be like what C++ does, but only for POD
> types. Just take const, immutable, whatever away when they're passed by
> value.


-- 
Dmitry Olshansky

On 7 July 2013 00:49, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 07/06/2013 04:06 PM, Manu wrote:
>
>> ...
>>
>>     It seems that your code works if you put the Template Type explicit:
>>     ----
>>     import std.stdio;
>>     import std.traits : Unqual;
>>
>>     void foo(T)(Unqual!T a) {
>>              writeln(typeof(a).stringof, " <-> ", T.stringof);
>>     }
>>
>>     void main() {
>>              int a;
>>              const int b;
>>              immutable int c;
>>
>>              //foo(c); /// Error
>>              foo!(typeof(a))(a);
>>              foo!(typeof(b))(b);
>>              foo!(typeof(c))(c);
>>     }
>>     ----
>>
>>
>> Indeed, hence my point that the type deduction is the key issue here. It should be possible... maybe a bit tricky though.
>>
>
> The key issue is that the syntax void foo(T)(Unqual!T a); denotes roughly the opposite of what you think it denotes. Basically, inference is instructed to find a T, such that Unqual!T is the argument type.
>

Perhaps what you say is true, but does that mean something to the effect of what I'm trying to demonstrate is impossible? I feel like it would be a much cleaner solution than any of the others presented in this thread...

On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote:
> [..] I feel like it would be a much cleaner solution than any of
> the others presented in this thread...

I think Artur's solution is the cleanest one because it changes the default behaviour to a more sensible one: it is useful to keep the full type information only if the type isn't implicitly convertible from immutable to mutable and back again... otherwise keeping the full type information along only causes inconvenience.

On 7 July 2013 16:02, TommiT <tommitissari@hotmail.com> wrote:

> On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote:
>
>> [..] I feel like it would be a much cleaner solution than any of
>>
>> the others presented in this thread...
>>
>
> I think Artur's solution is the cleanest one because it changes the default behaviour to a more sensible one: it is useful to keep the full type information only if the type isn't implicitly convertible from immutable to mutable and back again... otherwise keeping the full type information along only causes inconvenience.
>

Maybe so, but I just have my suspicions that it will never fly, and I think
a solution here is actually pretty important.
This is demonstrably one of the biggest issues with C++, and since
templates are so much more convenient in D, I expect time will show it to
be far worse in D than it already is in C++.

On 07/07/13 08:22, Manu wrote:
> On 7 July 2013 16:02, TommiT <tommitissari@hotmail.com <mailto:tommitissari@hotmail.com>> wrote:
> 
>     On Saturday, 6 July 2013 at 23:11:26 UTC, Manu wrote:
> 
>         [..] I feel like it would be a much cleaner solution than any of
> 
>         the others presented in this thread...
> 
> 
>     I think Artur's solution is the cleanest one because it changes the default behaviour to a more sensible one: it is useful to keep the full type information only if the type isn't implicitly convertible from immutable to mutable and back again... otherwise keeping the full type information along only causes inconvenience.
> 
> 
> Maybe so, but I just have my suspicions that it will never fly, and I think a solution here is actually pretty important.
> This is demonstrably one of the biggest issues with C++, and since templates are so much more convenient in D, I expect time will show it to be far worse in D than it already is in C++.

It's like the virtual-by-default situation - if the default isn't fixed everybody will ignoring this issue, until it actually becomes a problem. Then they (or more likely somebody else) will have tp do a clean up pass, and then the cycle will repeat. Almost nobody will start with

   auto f(T=Unqual!_T)(_T val) { /*...*/ } // example new syntax

Fixing "just" IFTI should be relatively safe, affecting only a tiny
amount of code, if any.  These kind of const changes happen more
or less randomly anyway, from the POV of the called function.
"const a=1; f(a+a); f(a+1);" -- this already creates two different
instances of 'f(T)(T)".

Yeah, fixing the expression types would be an even better idea (so that "const int + const int" == "int" etc) but that could have a larger impact, as it would affect a lot of 'auto' declarations.

artur

On Sunday, 7 July 2013 at 06:22:17 UTC, Manu wrote:
> On 7 July 2013 16:02, TommiT <tommitissari@hotmail.com> wrote:
>> I think Artur's solution is the cleanest one [..]
>
> Maybe so, but I just have my suspicions that it will never fly, and I think a solution here is actually pretty important.

You think it won't fly because it's a breaking change? I also think a solution is needed.

Earlier you said that your suggestion either is implementable or it isn't. If you put it that way, the answer must be that it is implementable, because if a problem is computable then it is possible to write a compiler that can compute it given that there's an ambiguous solution to the problem. But since compiler writers are only human, I think there might the third possibility which is that it's just a too big of an undertaking for a small group of humans to write that compiler. For example here's an example where the compiler would need to solve the equation:
cast(int) (3.5 ^^ x * x ^^ 4 + 5 * x) == 206
for x. And not only does the compiler need to figure out an answer to the problem, it needs to figure out that there aren't multiple answers to the problem.

struct Soo(int n) { }

template Too(int x)
{
    alias Too = Soo!(cast(int) (3.5 ^^ x * x ^^ 4 + 5 * x));
}

void foo(int n)(Too!n) { }

void main()
{
    Soo!206 s;
    foo(s); // should call foo!2(s)
}