[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 Sky Thirteenth changed: What|Removed |Added Severity|normal |major --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 b2.t...@gmx.com changed: What|Removed |Added Hardware|x86_64 |All OS|Windows |All --- Comment #1 from b2.t...@gmx.com --- 1. I don't see the first function working. (https://dpaste.dzfl.pl/2b462faf70b0). WHen you try to instantiate both gives the same error. 2. If you don't do partial instantiation then your alias can be declared more simply as 'alias TestAlias = TestType;' 3. The real problem you encounter here is that TestType template argument cannot be deduced from the value passed to the constructor: struct TestType(T) { T data; } void main() { auto a = TestType(0); // same error } This is exactly what happens when you call TestFunctionA. For example you can replace the declaration by: void testFunctionB(T)(T arg) and if you call testFunction(TestType(0)); you get exactly the same error. --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 b2.t...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from b2.t...@gmx.com --- This is not a bug, this is issue 6082. IFTI doesn't support this yet. *** This issue has been marked as a duplicate of issue 6082 *** --
[Issue 6082] Constructors of templated types should be callable via IFTI
https://issues.dlang.org/show_bug.cgi?id=6082 b2.t...@gmx.com changed: What|Removed |Added CC||sky.13th...@gmail.com --- Comment #3 from b2.t...@gmx.com --- *** Issue 16465 has been marked as a duplicate of this issue. *** --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 --- Comment #3 from Sky Thirteenth --- (In reply to b2.temp from comment #2) > This is not a bug, this is issue 6082. IFTI doesn't support this yet. > > *** This issue has been marked as a duplicate of issue 6082 *** Sorry, but not we have some misunderstanding. Question is not about a constructors. It about a types. Here is more clear example: https://dpaste.dzfl.pl/2c8e1c350182 --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 Sky Thirteenth changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #4 from Sky Thirteenth --- (In addition to Sky Thirteenth from comment #3) > (In reply to b2.temp from comment #2) > > This is not a bug, this is issue 6082. IFTI doesn't support this yet. > > > > *** This issue has been marked as a duplicate of issue 6082 *** > > Sorry, but not we have some misunderstanding. > > Question is not about a constructors. It about a types. > > Here is more clear example: https://dpaste.dzfl.pl/2c8e1c350182 Template aliases does not work correct while it used with template functions. Compiler just somehow can't understand that is the same type, rather than different. --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 --- Comment #5 from b2.t...@gmx.com --- I confirm the misunderstanding. If you permit I would suggest you to close this one but to open a new issue using your second example. The first one really represented issue 6082. The second is perfectly clear. --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 --- Comment #6 from Sky Thirteenth --- (In reply to b2.temp from comment #5) > I confirm the misunderstanding. If you permit I would suggest you to close > this one but to open a new issue using your second example. The first one > really represented issue 6082. The second is perfectly clear. Yes, sure. But, you will create new one, or should I? --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 --- Comment #7 from b2.t...@gmx.com --- (In reply to Sky Thirteenth from comment #6) > (In reply to b2.temp from comment #5) > > I confirm the misunderstanding. If you permit I would suggest you to close > > this one but to open a new issue using your second example. The first one > > really represented issue 6082. The second is perfectly clear. > > Yes, sure. > But, you will create new one, or should I? I wont, you will. --
[Issue 16486] New: Compiler see template alias like a separate type in template function definition
https://issues.dlang.org/show_bug.cgi?id=16486 Issue ID: 16486 Summary: Compiler see template alias like a separate type in template function definition Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: sky.13th...@gmail.com For example, here the type: ``` struct TestType(T, size_t size) { T[size] data; } ``` And, for some reason, We want to have some aliases on it: ``` alias TestAliasA= TestType; alias TestAliasB(T) = TestType!(T, 3); ``` Then We, obviously, somehow use them: ``` void testFunctionA(T)(TestType!(T, 3) arg) { writeln( arg ); } void testFunctionB(T)(TestAliasA!(T, 3) arg) { writeln( arg ); } void testFunctionC(T)(TestAliasB!T arg) { writeln( arg ); } ``` But there is the problem with usage of `testFunctionC`. It cause compiler error. It just simply can not recognize that TestAliasB!T and TestType!(int, 3) is the same type, rather than different. Here complete example: https://dpaste.dzfl.pl/2c8e1c350182 --
[Issue 16465] Template alias does not get unwrapped in templated functions
https://issues.dlang.org/show_bug.cgi?id=16465 --- Comment #8 from Sky Thirteenth --- (In reply to b2.temp from comment #7) > (In reply to Sky Thirteenth from comment #6) > > (In reply to b2.temp from comment #5) > > > I confirm the misunderstanding. If you permit I would suggest you to close > > > this one but to open a new issue using your second example. The first one > > > really represented issue 6082. The second is perfectly clear. > > > > Yes, sure. > > But, you will create new one, or should I? > > I wont, you will. OK, thank you. Here the new one https://issues.dlang.org/show_bug.cgi?id=16486 --
[Issue 16486] Compiler see template alias like a separate type in template function definition
https://issues.dlang.org/show_bug.cgi?id=16486 b2.t...@gmx.com changed: What|Removed |Added Hardware|x86_64 |All OS|Windows |All --
[Issue 11331] Inefficient initialization of struct with members = void
https://issues.dlang.org/show_bug.cgi?id=11331 gyroh...@gmail.com changed: What|Removed |Added CC||gyroh...@gmail.com --- Comment #5 from gyroh...@gmail.com --- Is anything being worked on to change this? --
[Issue 16487] New: Add function to obtain the available disk space
https://issues.dlang.org/show_bug.cgi?id=16487 Issue ID: 16487 Summary: Add function to obtain the available disk space Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: jbc.enge...@gmail.com Would be nice to have a function that returns the available disk space on a given path (file, directory, server share). Something like this: ``` // Returns ulong.max when the available disk space could not be determined. ulong getAvailableDiskSpace(string path) { import std.string: toStringz; version (WINDOWS) { import core.sys.windows.winbase; ULARGE_INTEGER freeBytesAvailable; auto pathCstr = (driveName(path) ~ dirSeparator).toStringz(); bool success = GetDiskFreeSpaceExW(path, &freeBytesAvailable, null, null); return success ? free_bytes.QuadPart : ulong.max; } else { import core.sys.posix.sys.statvfs; statvfs_t stats; int err = statvfs(path.toStringz(), &stats); return !err ? stats.f_bavail * stats.f_frsize : ulong.max; } } ``` --
[Issue 16486] Compiler see template alias like a separate type in template function definition
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 15903] [REG 2.071] module foo.bar is not accessible here, perhaps add 'static import foo.bar; (already there)
https://issues.dlang.org/show_bug.cgi?id=15903 Martin Nowak changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All --- Comment #6 from Martin Nowak --- Can't reproduce the issues of comment 0 and comment 4, please retest and provide a complete test case. Comment 3 is clearly a duplicate of issue 15000. --
[Issue 15903] [REG 2.071] module foo.bar is not accessible here, perhaps add 'static import foo.bar; (already there)
https://issues.dlang.org/show_bug.cgi?id=15903 --- Comment #7 from Martin Nowak --- (In reply to Martin Nowak from comment #6) > Comment 3 is clearly a duplicate of issue 15000. issue 15900 --
[Issue 15897] private base class method not seen through derived class
https://issues.dlang.org/show_bug.cgi?id=15897 --- Comment #19 from Martin Nowak --- (In reply to Sophie from comment #18) > Isn't this what the "protected" access modifier is for? Yes, protected would be the choice for inheriting a function. Here the question was whether a private member of a base class, should be visible for derived classes in the base class' module. Not revealing that private member, b/c the derived class is in a different module, is a semantic change introduced by DIP22, hence the deprecation. --
[Issue 15983] [REG 2.071] Symbol visibility in derived classes
https://issues.dlang.org/show_bug.cgi?id=15983 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Martin Nowak --- You can get the base class like so. void foo(T)(T t) if (is(T Base == super)) { Base.Something something; } Still need to have all base classes in a the same module/package as the function. Would be interested to know, why you rely on duck typing of the base class. Also maybe it's not worth to hide Something when it's a common property of your class hierarchy. *** This issue has been marked as a duplicate of issue 15897 *** --
[Issue 15897] private base class method not seen through derived class
https://issues.dlang.org/show_bug.cgi?id=15897 Martin Nowak changed: What|Removed |Added CC||renezwanenb...@gmail.com --- Comment #20 from Martin Nowak --- *** Issue 15983 has been marked as a duplicate of this issue. *** --
[Issue 16086] Imported function name shadows alias this member
https://issues.dlang.org/show_bug.cgi?id=16086 Martin Nowak changed: What|Removed |Added Priority|P1 |P2 Severity|regression |normal --- Comment #2 from Martin Nowak --- This issue is not a result of the lookup change, but happens because tail was newly added to std.range in 2.071.x. Alias this and opDispatch was and still is resolved after an exhaustive search. Might be worthwhile to think about performing alias this resolution before searching imported modules, to avoid such breakage due to upstream library changes. --
[Issue 16243] wrong C++ argument passing with empty struct and 6 integers
https://issues.dlang.org/show_bug.cgi?id=16243 Martin Nowak changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #7 from Martin Nowak --- (In reply to kinke from comment #4) > clang doesn't pass empty structs at all for 32-bit, while GCC does. We have > such a special case in LDC too for 32-bit OSX, where we assume clang, but > not for 32-bit Linux, where we assume GCC. See > https://github.com/ldc-developers/ldc/blob/master/gen/abi-x86.cpp#L214. Thanks, assuming clang by default on OSX indeed seems like a reasonable solution. We also have that issue with GCC5's C++ ABI change (http://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/), so detecting the actual compiler might be helpful as well. (In reply to Jacob Carlborg from comment #6) > There's a long time since Apple switched to Clang. GCC is dead on Apple > platforms. I've mentioned this several times that the autotester should > switch to Clang. Yes, would be good if we updated the auto-testers to use clang @Brad. --
[Issue 16243] wrong C++ argument passing with empty struct and 6 integers
https://issues.dlang.org/show_bug.cgi?id=16243 --- Comment #8 from Jacob Carlborg --- (In reply to Martin Nowak from comment #7) > We also have that issue with GCC5's C++ ABI change > (http://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/), so > detecting the actual compiler might be helpful as well. As far as I understand, it's configurable if that ABI should be used or not. So just detecting the compiler is not enough, unless we decide to only support one ABI. --