[Issue 1951] Remove SFINAE
http://d.puremagic.com/issues/show_bug.cgi?id=1951
--- Comment #2 from Don 2012-11-16 00:33:22 PST ---
Here's the first example from
http://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error
translated into D.
---
struct Test {
alias int foo;
}
void f(T)(T.foo x) {} // Definition #1
void f(T)(T x) {}// Definition #2
void main() {
f!(Test)(10); // Call #1.
f!(int)(10); // C++ No error (even though there is no int::foo) thanks to
SFINAE.
}
bug.d(5): Error: no property 'foo' for type 'int'
bug.d(5): Error: T.foo is used as a type
Same thing with every other SFINAE example I've been able to find. The
behaviour is the same on D1 and D2.
Does D actually have SFINAE???
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8720] ICE(glue.c, !vthis->csym)
http://d.puremagic.com/issues/show_bug.cgi?id=8720 --- Comment #3 from tmn 2012-11-16 00:34:54 PST --- This is definitely same as issue 8071, which is marked as a duplicate of issue 4481. However, I am not sure if this actually is the same as issue 4481. At least the original code given in 4481 compiles fine for me. On the other hand, the second example given by Ola �sttveit again triggers the same error. In fact, I hit this too when trying to use std.algorithm as in 8071. In many cases the bug makes usage of std.algorithm impossible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1951] Remove SFINAE
http://d.puremagic.com/issues/show_bug.cgi?id=1951
--- Comment #3 from Kenji Hara 2012-11-16 00:53:12 PST ---
(In reply to comment #2)
> ---
> struct Test {
> alias int foo;
> }
>
> void f(T)(T.foo x) {} // Definition #1
>
> void f(T)(T x) {}// Definition #2
>
> void main() {
> f!(Test)(10); // Call #1.
> f!(int)(10); // C++ No error (even though there is no int::foo) thanks to
> SFINAE.
> }
>
> bug.d(5): Error: no property 'foo' for type 'int'
> bug.d(5): Error: T.foo is used as a type
>
I think that is not a lack SFINAE, rather the type deduction mechanism issue.
In current, T.foo is not treated as a *partially parameterized* type name.
I recently filed bug 9022 to support such type deduction.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1012] cannot instantiate template with no or default arguments without !()
http://d.puremagic.com/issues/show_bug.cgi?id=1012 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #6 from Kenji Hara 2012-11-16 01:22:06 PST --- D2 pull: https://github.com/D-Programming-Language/dmd/pull/1295 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9022] IFTI should support enclosing type/scope deduction
http://d.puremagic.com/issues/show_bug.cgi?id=9022 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #4 from Kenji Hara 2012-11-16 01:39:24 PST --- https://github.com/D-Programming-Language/dmd/pull/1296 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9018] __traits(compiles, ...) is true on second check for same incompilable code
http://d.puremagic.com/issues/show_bug.cgi?id=9018 --- Comment #2 from github-bugzi...@puremagic.com 2012-11-16 01:48:31 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f60d9238e261c756caded36012f0415710a0b63a fix Issue 9018 - __traits(compiles, ...) is true on second check for same incompilable code https://github.com/D-Programming-Language/dmd/commit/f968f3c29d10d537d1f9f039151eed6df70d5fe5 Merge pull request #1294 from 9rnsr/fix9018 Issue 9018 - __traits(compiles, ...) is true on second check for same incompilable code -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9033] New: Remove __thread from the language
http://d.puremagic.com/issues/show_bug.cgi?id=9033 Summary: Remove __thread from the language Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: clugd...@yahoo.com.au --- Comment #0 from Don 2012-11-16 02:01:44 PST --- It is obsolete, but fairly harmless since __keywords are reserved words anyway. It was never really part of the language. It was listed in the changelog as: "Added __thread storage class for thread local storage. This is for testing purposes only to check out the machinery in the back end. The front end design of this will change." (2.013, Apr 2008). It was made completely obsolete by 2.030 (May 2009). First step is to remove it from the website. It also needs to be removed from the test suite, and then dropped from the compiler. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9034] New: errors of conversions in format.d
http://d.puremagic.com/issues/show_bug.cgi?id=9034 Summary: errors of conversions in format.d Product: D Version: D2 Platform: x86_64 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: gcl...@gmx.fr --- Comment #0 from Gilles Cloup 2012-11-16 04:30:00 PST --- dmd2\src\phobos\std\format.d(4573): Error: cannot implicitly convert expression (fbuf.length) of type ulong to uint dmd2\src\phobos\std\format.d(4575): Error: cannot implicitly convert expression (& sl) of type uint* to ulong* dmd2\src\phobos\std\format.d(4578): Error: cannot implicitly convert expression (fbuf.length * 2LU) of type ulong to uint -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9035] New: Nested struct `init` is lvalue and can be modified
http://d.puremagic.com/issues/show_bug.cgi?id=9035
Summary: Nested struct `init` is lvalue and can be modified
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij 2012-11-16
15:56:27 MSK ---
---
struct S { }
void f(T)(auto ref T t)
{ static assert(!__traits(isRef, t)); }
void main()
{
f(S.init); // ok, rvalue
f(S());// ok, rvalue
int i;
struct Nested
{ int j = 0; void f() { ++i; } }
f(Nested()); // ok, rvalue
f(Nested.init); // fails, lvalue
assert(Nested.init.j == 0);
(ref n) { n.j = 5; }(Nested.init);
assert(Nested.init.j == 0); // fails, j is 5
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7947] typeof on anonymous function literal returns void
http://d.puremagic.com/issues/show_bug.cgi?id=7947 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #3 from yebblies 2012-11-17 00:21:17 EST --- There is another case where using void as the type of template lambdas causes problems, (but of course I can't remember where). It might be worth adding a Ttemplate dummy type and just printing "template" here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9034] errors of conversions in format.d
http://d.puremagic.com/issues/show_bug.cgi?id=9034 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies 2012-11-17 00:59:29 EST --- A minimal test case to go with those errors would be helpful. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9033] Remove __thread from the language
http://d.puremagic.com/issues/show_bug.cgi?id=9033 --- Comment #1 from github-bugzi...@puremagic.com 2012-11-16 06:41:15 PST --- Commits pushed to master at https://github.com/D-Programming-Language/d-programming-language.org https://github.com/D-Programming-Language/d-programming-language.org/commit/bd673ff02558131ae7b79803c606f812d633075a Bug 9033 Remove __thread from list of keywords It was used only for internal testing, never documented, and has been obsolete for three years. https://github.com/D-Programming-Language/d-programming-language.org/commit/a33fdf6db0705408b6722925f3049d30978a9390 Merge pull request #198 from donc/remove__thread Bug 9033 Remove __thread from list of keywords -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1012] cannot instantiate template with no or default arguments without !()
http://d.puremagic.com/issues/show_bug.cgi?id=1012 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #7 from Walter Bright 2012-11-16 10:39:26 PST --- I have severe misgivings about this. C has had problems with implicitly taking the address of a function. D has had a number of problems with implicitly calling a function (the @property thing). It's just ambiguous in many cases, and leads to trouble, trouble, trouble. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1012] cannot instantiate template with no or default arguments without !()
http://d.puremagic.com/issues/show_bug.cgi?id=1012 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #8 from Jonathan M Davis 2012-11-16 10:58:46 PST --- > I have severe misgivings about this. I concur. It seems like it just begging for trouble when providing minimal gain. Not to mention that it would harm code readability in many cases, which will therefore harm code maintainability. issue# 6082 might be reasonable to implement (I don't know), in which case the example here would compile, but that would be restricted specifically to constructors. Making it so that templates in general can be instantiated without !() if they don't need any arguments is a bad idea IHMO. And I think that this post on the newsgroup is a good example of why this is a bad idea: http://forum.dlang.org/post/vmipipnhyiilketby...@forum.dlang.org -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1012] cannot instantiate template with no or default arguments without !()
http://d.puremagic.com/issues/show_bug.cgi?id=1012 Jakob Ovrum changed: What|Removed |Added CC||jakobov...@gmail.com --- Comment #9 from Jakob Ovrum 2012-11-16 11:14:54 PST --- (In reply to comment #8) > issue# 6082 might be reasonable to implement (I don't know), It's not possible in the general case. http://stackoverflow.com/questions/13151072/ It might still be an attractive feature to have for specific, common cases, but it would either have to be defined as a "compiler's best effort" thing, which hurts portability, or defined to only work for a select few specific cases. The latter is what's currently done for IFTI, but the rules are intuitive, especially thanks to eponymous templates. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9036] New: postblit is called for nested structs when assigning `init`
http://d.puremagic.com/issues/show_bug.cgi?id=9036
Summary: postblit is called for nested structs when assigning
`init`
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij 2012-11-16
22:40:07 MSK ---
Note that we have zero context pointer in such postblit call:
---
int i;
struct S
{ this(this) { ++i; } }
void main()
{
S s = S.init;
assert(i == 0); // postblit not called
s = S.init;
assert(i == 0); // postblit not called
int k;
static int j = 0;
struct N
{
this(this)
{
++j;
assert(this.tupleof[$-1] != null); // fails
}
void f() { ++k; }
}
N n = N.init;
assert(j == 0); // fails, j = 1, postblit called
n = N.init;
assert(j == 0); // fails, j = 2, postblit called
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7220] Bad initialization when using mixin to generate a static field in a -lib'rary
http://d.puremagic.com/issues/show_bug.cgi?id=7220 --- Comment #5 from github-bugzi...@puremagic.com 2012-11-16 13:49:29 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0cb89561a45edd46440d51e5807e4e1434735d24 fix Issue 7220 - Bad initialization when using mixin to generate a static field in a -lib'rary -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8987] Compiling using '-O -release' options yield 'Internal error: backend\cgcod.c 1663'
http://d.puremagic.com/issues/show_bug.cgi?id=8987 --- Comment #2 from github-bugzi...@puremagic.com 2012-11-16 13:49:21 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ebbf254c4ed938e9e3b29e688ba5d07098696e5e fix Issue 8987 - Compiling using -O -release options yield Internal error: backend\cgcod.c 1663 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8966] ICE(cgcod.c) when passing cfloat argument with indirection
http://d.puremagic.com/issues/show_bug.cgi?id=8966 --- Comment #2 from github-bugzi...@puremagic.com 2012-11-16 13:49:26 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b319cb6f48ba7a00e9bbd41e42e6ac1d0f99e1e7 fix Issue 8966 - ICE(cgcod.c) when passing cfloat argument with indirection -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4427] __traits should have isFunction, isVariable, etc
http://d.puremagic.com/issues/show_bug.cgi?id=4427 Rob T changed: What|Removed |Added CC||al...@ucora.com --- Comment #6 from Rob T 2012-11-16 14:07:14 PST --- (In reply to comment #2) > Good points, though would == function check when it was a function pointer > rather than a function? In either case, I think that you should be able to > check these in a consistent manner, which you can't do right now. With things > spread out between built-in constructs, __traits, and std.traits, it can be a > bit of a mess to figure out how to do something with compile-time reflection. > Even if something like isType were simply translated to is(T), I think that > having it would still be quite valuable since it would make the various > compile-time reflection facilities more consistent and uniform. I wasted an hour on this very issue because it's not obvious in the least how to do something like isStruct() for a template constraint. I don't mind using is( T == struct ), so long how to do such a thing (and other tests) is documented in an obvious place that someone is going to look at, like in the templates constraint section. That section currently has nothing in it of much help other than showing how to constrain a few basic types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4427] __traits should have isFunction, isVariable, etc
http://d.puremagic.com/issues/show_bug.cgi?id=4427 --- Comment #7 from Jonathan M Davis 2012-11-16 15:46:47 PST --- I had forgotten that I created this enhancement request, though I don't know how valid it is at this point given how powerful is expressions are (though how to fully use them isn't well enough known). > I wasted an hour on this very issue because it's not obvious in the least how > to do something like isStruct() for a template constraint. > I don't mind using is( T == struct ), so long how to do such a thing (and > other tests) is documented in an obvious place that someone is going to look > at, like in the templates constraint section. That section currently has > nothing in it of much help other than showing how to constrain a few basic > types. It's explained in the section on is expressions: http://dlang.org/expression.html#IsExpression However, that documentation is fairly sparse, and given the extreme flexibility and power (and therefore complication) of is expressions, we could really use a solid tutorial on them on the site. Phillippe Segaud has an extension tutorial on templates in general on github though: https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/dtemplates.pdf -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
