[Issue 16486] Compiler see template alias like a separate type in template function definition

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

Walter Bright  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=1807

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

ag0aep6g  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from ag0aep6g  ---


*** This issue has been marked as a duplicate of issue 10884 ***

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

--- Comment #6 from Sky Thirteenth  ---
(In reply to ag0aep6g from comment #5)
> (In reply to Sky Thirteenth from comment #4)
> > it can be pretty useful feature.
> 
> Sure. I don't think anyone disputes that it could be a useful feature. So we
> keep the issue open as an enhancement request.
> 
> It's not a bug, because, as far as I know, there has been no intention to
> support the feature, yet. That is, the language specification doesn't say
> that it should work, and there's no (buggy) code in the compiler that
> attempts to do it.

Then, OK. 

So, at least now I will know about it. 
And also know that this feature may appear later, in a future.

Thank You for Your time spend on this. =)

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

--- Comment #5 from ag0ae...@gmail.com ---
(In reply to Sky Thirteenth from comment #4)
> it can be pretty useful feature.

Sure. I don't think anyone disputes that it could be a useful feature. So we
keep the issue open as an enhancement request.

It's not a bug, because, as far as I know, there has been no intention to
support the feature, yet. That is, the language specification doesn't say that
it should work, and there's no (buggy) code in the compiler that attempts to do
it.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

--- Comment #4 from Sky Thirteenth  ---
(In reply to Steven Schveighoffer from comment #3)
> The issue is that the compiler doesn't replace the alias until AFTER
> instantiation.
> 
> It should be able to see that:
> 
> testFunctionC(T)(TestAliasB!T arg)
> 
> is the same as 
> 
> testFunctionC(T)(TestType!(T, 3) arg)
> 
> and reduce basically to the same thing as testFunctionA
> 
> Still definitely an enhancement, as there is no definition of how the
> compiler will work backwards through template instantiations.
> 
> It may be a duplicate, I distinctly remember wishing for this kind of thing
> back when D2 was in infancy.

Actually, in my opinion, as it acts now, looks wrong, because this feature is
not used at full power. 

We can use templates and template alias, while declare variables, but can't do
the same thing while describe arguments for other templates(no matter is it
type or function). Don't you feel wrong about it?

The meaning of this features, is to simplify things. But in this case we need
to write something like this:
```
auto foo( That )( What.TheHell!(is(That : Thing) && How!(IShould!(Use!That)))
arg )
{
//...
}
```
Rather then just write down this:
```
auto foo( That )( CatInABag!That arg )
{
//...
}
```

Of course, now I'm exaggerating things, but still it can be pretty useful
feature.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com
   Severity|major   |enhancement

--- Comment #3 from Steven Schveighoffer  ---
The issue is that the compiler doesn't replace the alias until AFTER
instantiation.

It should be able to see that:

testFunctionC(T)(TestAliasB!T arg)

is the same as 

testFunctionC(T)(TestType!(T, 3) arg)

and reduce basically to the same thing as testFunctionA

Still definitely an enhancement, as there is no definition of how the compiler
will work backwards through template instantiations.

It may be a duplicate, I distinctly remember wishing for this kind of thing
back when D2 was in infancy.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

--- Comment #2 from Sky Thirteenth  ---
(In reply to ag0aep6g from comment #1)
> Reduced to the core:
> 
> 
> struct TestType(T) {}
> alias TestAlias(T) = TestType!T;
> void testFunction(T)(TestAlias!T arg) {}
> 
> void main()
> {
> TestAlias!int testObj;
> testFunction(testObj); /* "cannot deduce function from argument types
> !()(TestType!int)" */
> }
> 
> 
> I don't think this is supposed to work.
> 
> It works when testFunction's parameter is TestType!T, because testObj's type
> (TestType!int/TestAlias!int) carries the information that it's an
> instantiation of template TestType with argument int.
> 
> But the compiler has no simple way of telling how TestType!int relates to
> TestAlias!T. For example, TestAlias could be defined like this:
> 
> 
> template TestAlias(T)
> {
> static if (is(T == float)) alias TestAlias = TestType!int;
> else alias TestAlias = string;
> }
> 
> 
> With that, testFunction(TestType!int.init) would have to result in T =
> float. And with testFunction("") the compiler would have multiple choices
> for T.
> 
> With the original TestAlias it's more straight-forward, but the compiler
> would still have to analyze TestAlias's implementation. That's probably not
> feasible (maybe impossible) in the general case.
> 
> Maybe simple cases could be supported. But that would be an enhancement
> request, I think. And then there's always the question of where to draw the
> line, and if it's not better to minimize surprises by just rejecting any
> such code.

OK, I clearly understand the cost which it may take. But, don't You think that
this "limitation" is weird?

All of possible performance drop it's problem nor of compiler, nor of language,
but of programmer, who wrote this code.

It's already possible to construct complex types on compile time, so why We can
not do that for template functions too?

P.S.: For example, C++ allow this kind of calculations. Yes, in C++ it slow and
ugly looking, but it's not a fault of a concept. It's problem of realization.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Reduced to the core:


struct TestType(T) {}
alias TestAlias(T) = TestType!T;
void testFunction(T)(TestAlias!T arg) {}

void main()
{
TestAlias!int testObj;
testFunction(testObj); /* "cannot deduce function from argument types
!()(TestType!int)" */
}


I don't think this is supposed to work.

It works when testFunction's parameter is TestType!T, because testObj's type
(TestType!int/TestAlias!int) carries the information that it's an instantiation
of template TestType with argument int.

But the compiler has no simple way of telling how TestType!int relates to
TestAlias!T. For example, TestAlias could be defined like this:


template TestAlias(T)
{
static if (is(T == float)) alias TestAlias = TestType!int;
else alias TestAlias = string;
}


With that, testFunction(TestType!int.init) would have to result in T = float.
And with testFunction("") the compiler would have multiple choices for T.

With the original TestAlias it's more straight-forward, but the compiler would
still have to analyze TestAlias's implementation. That's probably not feasible
(maybe impossible) in the general case.

Maybe simple cases could be supported. But that would be an enhancement
request, I think. And then there's always the question of where to draw the
line, and if it's not better to minimize surprises by just rejecting any such
code.

--

[Issue 16486] Compiler see template alias like a separate type in template function definition

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16486

b2.t...@gmx.com changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Windows |All

--