[Issue 11718] [REG2.065a] Unintended mangled names conflict of nested template structs
https://d.puremagic.com/issues/show_bug.cgi?id=11718 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Summary|regression(git head): |[REG2.065a] Unintended |failed semantic analysis|mangled names conflict of ||nested template structs --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-12-11 23:56:29 PST --- https://github.com/D-Programming-Language/dmd/pull/2953 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11714] Improve error message for wrongly initialized thread-local class instances
https://d.puremagic.com/issues/show_bug.cgi?id=11714 --- Comment #7 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-12-12 02:18:32 PST --- (In reply to comment #6) With *a* reference to – I stripped out the articles trying to make the error message as concise as possible, and missed that it would distort the meaning. Easier to use with a reference to and with respect to respectively, for the two different cases (just for future reference:-). What I'm really concerned about, though, is that to me that message is still pretty much incomprehensible about what it is that I actually did wrong. Even when clarified with instructions about what to do to resolve it (initialize to null or use static this) it's not obvious about what I got wrong or why it's wrong. If I understand the logic right, the result of new MyClass is not knowable at compile time -- hence, a compile time constant; but inferring the former meaning from the latter is not obvious unless one already knows. Rather than requiring the programmer's knowledge and understanding to comprehend the error message, we should aim to use the error message to _increase_ the programmer's knowledge and understanding. So, I want an error message that idiots like me can read and go, Oh! THAT's why it's wrong, as well as understanding how to fix it. :-) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11723] Too many integer overflow errors
https://d.puremagic.com/issues/show_bug.cgi?id=11723 --- Comment #2 from github-bugzi...@puremagic.com 2013-12-12 02:47:45 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/343be8ec3576d2ffe0dcb5874ccc94d95e521ddc fix Issue 11723 - Too many integer overflow errors https://github.com/D-Programming-Language/dmd/commit/75c48b92070f7b4ba5dea15834fc09f373d0abfd Merge pull request #2948 from 9rnsr/fix11723 [REG2.065a] Issue 11723 - Too many integer overflow errors -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11726] ICE with ufcs on undefined identifier and opDispatch
https://d.puremagic.com/issues/show_bug.cgi?id=11726
yebblies yebbl...@gmail.com changed:
What|Removed |Added
Keywords||pull
Summary|ICE with ufcs on undefined |ICE with ufcs on undefined
|identifier |identifier and opDispatch
--- Comment #1 from yebblies yebbl...@gmail.com 2013-12-12 22:43:58 EST ---
struct S
{
auto opDispatch(string fn, Args...)(Args args)
{
}
}
void main() {
S().reserve(x.foo());
}
https://github.com/D-Programming-Language/dmd/pull/2954
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11728] New: compile error in std.bigint and -profile
https://d.puremagic.com/issues/show_bug.cgi?id=11728
Summary: compile error in std.bigint and -profile
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: yuri.musashi.miwa.tam...@gmail.com
--- Comment #0 from Musashi Tamura yuri.musashi.miwa.tam...@gmail.com
2013-12-12 03:43:33 PST ---
// aaa.d
import std.bigint;
void main() {
BigInt a = 0;
}
dmd -profile aaa
Error: 'std.internal.math.biguintcore.BigUint.__invariant' is not nothrow
This error is new in v2.064. (does not occur in v2.063)
Issue 10295 seems similar, but occurs in v2.063.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11728] compile error in std.bigint and -profile
https://d.puremagic.com/issues/show_bug.cgi?id=11728 --- Comment #1 from Musashi Tamura yuri.musashi.miwa.tam...@gmail.com 2013-12-12 03:47:46 PST --- Issue 10295 occurs in v2.063 and v2.064. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11727] [ICE] Returning an enum with no value from a function fails
https://d.puremagic.com/issues/show_bug.cgi?id=11727 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2013-12-12 22:51:16 EST --- I get: DMD v2.065 DEBUG testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(11): Error: incompatible types for ((returnEnum()) == (0)): 'n' and 'int' With the latest compiler. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11729] New: protected toString causes strange error message
https://d.puremagic.com/issues/show_bug.cgi?id=11729 Summary: protected toString causes strange error message Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: uplink.co...@googlemail.com --- Comment #0 from uplink.co...@googlemail.com 2013-12-12 04:46:32 PST --- Hello, if I declare a toString function protected, the compiler spills lots of error messages regardig Writers and Appenders. I find this very unhelpful. maybe another Template Contraint something along the lines of if (hasToString!T isCallable!T.toString) would be abit clearer. Cheers Uplink_Coder -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11723] Too many integer overflow errors
https://d.puremagic.com/issues/show_bug.cgi?id=11723 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11714] Improve error message for wrongly initialized thread-local class instances
https://d.puremagic.com/issues/show_bug.cgi?id=11714 --- Comment #8 from David Nadlinger c...@klickverbot.at 2013-12-12 05:51:44 PST --- (In reply to comment #7) If I understand the logic right, the result of new MyClass is not knowable at compile time Actually it is, otherwise you'd get a cannot be read/evaluated at compile time error in the constructor. The issue here is that in D global variables can only be initialized with statically known data (written to the relevant sections of the object file). For everything else, you need to use a static constructor. While support for converting CTFE class instances into data blobs to write to an object file was implemented a while ago, variables of a class type are of course references and need to point somewhere. Now, if a variable is either immutable or explicitly shared between threads, that's fine, you just emit the data once and then initialize the variable to point to that. However, for mutable, thread-local data, this simple scheme doesn't work, as it would require a new instance to be created for each new thread. I didn't really think about whether it would be possible to resolve that situation by emitting all the instance data into the TLS section yet, but this certainly isn't implemented in DMD right now. Thus, initializing class references that are (potentially) modified from more than one thread with CTFE instances is disallowed. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11730] New: associative array with Nullable!SysTime values: Called `get' on null Nullable!SysTime.
https://d.puremagic.com/issues/show_bug.cgi?id=11730
Summary: associative array with Nullable!SysTime values: Called
`get' on null Nullable!SysTime.
Product: D
Version: D2
Platform: All
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: kroepli...@googlemail.com
--- Comment #0 from Mario Kroeplin kroepli...@googlemail.com 2013-12-12
06:31:34 PST ---
The following program throws on D 2.064.2:
import std.datetime;
import std.typecons;
void main()
{
Nullable!SysTime[string] map;
map[foo] = Nullable!SysTime();
}
core.exception.AssertError@.dvm/compilers/dmd-2.064.2/bin/../src/phobos/std/typecons.d(1233):
Called `get' on null Nullable!SysTime.
It works on D 2.063.2.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11728] compile error in std.bigint and -profile
https://d.puremagic.com/issues/show_bug.cgi?id=11728 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2013-12-13 01:52:53 EST --- Same sort of thing as issue 11375 - the nothrow inference/checking in FuncDeclaration::semantic is a mess. The general problem is the compiler checks/infers nothrowness, then adds more stuff to the function body. The error occurs because later the compiler uses blockExit(tf-isnothrow) to decide if the profiling exit code needs to be wrapped in a try-finally or not. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11098] template instance x cannot use local y as parameter to non-global template z
https://d.puremagic.com/issues/show_bug.cgi?id=11098
Ralph Tandetzky ralph.tandetz...@gmail.com changed:
What|Removed |Added
CC||ralph.tandetz...@gmail.com
--- Comment #1 from Ralph Tandetzky ralph.tandetz...@gmail.com 2013-12-12
07:03:28 PST ---
I got the same problem with DMD64 D Compiler v2.063.2 on Linux Mint with the
following minimal code example:
struct S
{
void f(alias F)()
{
}
}
void main()
{
S.init.f!( x=x ); // error
}
I get the following error message:
test.d(10): Error: template instance f!(__lambda2) cannot use local
'__lambda2(__T1)(x)' as parameter to non-global template f(alias F)()
The UFCS form of f works though:
struct S
{
}
void f(alias F)( S )
{
}
void main()
{
S.init.f!( x=x ); // works
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11731] New: private enum behavior
https://d.puremagic.com/issues/show_bug.cgi?id=11731
Summary: private enum behavior
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: yuri.musashi.miwa.tam...@gmail.com
--- Comment #0 from Musashi Tamura yuri.musashi.miwa.tam...@gmail.com
2013-12-12 07:07:04 PST ---
// module1.d
private enum X = 1;
// main1.d
import module1;
void main() {
int i = X;
}
// module2.d
private enum { X = 1 }
// main2.d
import module2;
void main() {
int i = X;
}
dmd main1
main1.d(4): Error: module main1 module1.X is private
dmd main2
(no error)
Is it a correct behavior?
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11727] [ICE] Returning an enum with no value from a function fails
https://d.puremagic.com/issues/show_bug.cgi?id=11727 --- Comment #2 from monkeywork...@hotmail.com 2013-12-12 09:10:54 PST --- (In reply to comment #1) I get: DMD v2.065 DEBUG testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(4): Error: enum testx.returnEnum.n is forward referenced looking for base type testx.d(11): Error: incompatible types for ((returnEnum()) == (0)): 'n' and 'int' With the latest compiler. My mistake, I tested this on Dpaste and must not have set it to Git HEAD. Still, should this be changed to rejects-valid? It seems to me that n should default to type int and value 0. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11732] New: Ternary operator type unification problems with dstrings
https://d.puremagic.com/issues/show_bug.cgi?id=11732
Summary: Ternary operator type unification problems with
dstrings
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-12-12 10:09:07 PST ---
Title:
Component: dmd
Severity:
Code number:
Keywords:
Outcome:
Is done: no
See also:
I am not sure this is a but, it seems like one:
void main() {
bool test;
string s1 = test ? : null; // OK
dstring s2 = test ? d : null; // OK
dstring s3 = test ? : ; // OK
dstring s4 = test ? : null; // error
dstring[] a = test ? [d] : null; // OK
dstring[] b = test ? [] : null; // error
}
dmd 2.065alpha gives:
temp.d(6): Error: cannot implicitly convert expression (test ? : null) of
type string to immutable(dchar)[]
temp.d(8): Error: cannot implicitly convert expression (test ? [] : null) of
type string[] to immutable(dchar)[][]
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11733] New: Refuse int indexing of associative arrays with char keys
https://d.puremagic.com/issues/show_bug.cgi?id=11733
Summary: Refuse int indexing of associative arrays with char
keys
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-12-12 10:11:20 PST ---
I think this code should be disallowed:
void main() {
int[char] aa1;
int[dchar] aa2;
auto r1 = aa1[0];
auto r2 = aa2[0];
}
dmd 2.065alpha compiles it with no errors, and gives at run-time:
core.exception.RangeError@temp(4): Range violation
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11726] ICE with ufcs on undefined identifier and opDispatch
https://d.puremagic.com/issues/show_bug.cgi?id=11726 --- Comment #2 from github-bugzi...@puremagic.com 2013-12-12 13:45:00 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e36b695165ed055f704d14e613df35d707bd739d Fix Issue 11726 - ICE with ufcs on undefined identifier and opDispatch https://github.com/D-Programming-Language/dmd/commit/0e583e5e69ef4e57fab2fda2d4418de21cf64a81 Merge pull request #2954 from yebblies/issue11726 Issue 11726 - ICE with ufcs on undefined identifier and opDispatch -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5747] cannot cast away shared if opCast defined
https://d.puremagic.com/issues/show_bug.cgi?id=5747
--- Comment #9 from Max Samukha samu...@voliacable.com 2013-12-12 14:08:45
PST ---
(In reply to comment #7)
(In reply to comment #6)
(In reply to comment #4)
{
return this; //This fails
return cast(T) this; //This overflows
}
That's expected. It is easy to break the recursion:
Your example snippet still overflows for me for the initial use case:
It doesn't with dmd 2.064. But that's irrelevant. As I said, it is trivial to
avoid recursion, contrary to your claim that it is impossible.
void main()
{
immutable(S) s;
auto b = cast(S)(s); //How to do this?
}
I think the fix to issue 11722 has introduced an unnecessary limitation
(provided other annoyances are removed, such as opCast not being called if
types match exactly).
*What* limitations?
The limitation that I won't be able to intercept the qualifier-only cast down
the road if the need emerges. The limitation that you've just unnecessarily
introduced.
If we *really* wanted to overload a qualifier cast, then arguably, we could
add an enhancement request for something like:
No. That would be not an enhancement. That would be a bug report requesting the
removal of an necessarily introduced limitation.
auto opCast(); //Removes qualifier cast
auto opCast(const); //Adds const
auto opCast(shared); //Adds shared
That's not necessary since the general case of type cast handles the specific
case of qualifier-only cast perfectly.
But I really don't see how a *type* cast should interfere a *qualifier* cast.
Qualifier cast *is* a special case of type cast!
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11726] ICE with ufcs on undefined identifier and opDispatch
https://d.puremagic.com/issues/show_bug.cgi?id=11726 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11727] Repeated error message with using forward referenced enum as variable
https://d.puremagic.com/issues/show_bug.cgi?id=11727 yebblies yebbl...@gmail.com changed: What|Removed |Added Keywords||diagnostic Summary|[ICE] Returning an enum |Repeated error message with |with no value from a|using forward referenced |function fails |enum as variable Severity|critical|normal --- Comment #3 from yebblies yebbl...@gmail.com 2013-12-13 11:42:44 EST --- (In reply to comment #2) My mistake, I tested this on Dpaste and must not have set it to Git HEAD. Still, should this be changed to rejects-valid? It seems to me that n should default to type int and value 0. enum n; isn't an enum variable with no value, it's a forward declaration of an enum type 'n'. (like struct s;) Enum variables must always have an initializer. The error message obviously could be improved. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11727] Repeated error message with using forward referenced enum as variable
https://d.puremagic.com/issues/show_bug.cgi?id=11727 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|Other |All OS/Version|Other |All --- Comment #4 from Kenji Hara k.hara...@gmail.com 2013-12-12 17:26:22 PST --- https://github.com/D-Programming-Language/dmd/pull/2956 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10369] Deprecate unordered floating point comparisons (!=, etc) and later remove them
https://d.puremagic.com/issues/show_bug.cgi?id=10369 --- Comment #9 from github-bugzi...@puremagic.com 2013-12-12 19:07:47 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/97cebadfc75a332d79d00fc31e1ceed709813761 Fix Issue 10369 - Deprecate unordered floating point comparisons https://github.com/D-Programming-Language/dmd/commit/38e01f66e7e38a3be09b8b80947022f4117b0d51 Merge pull request #2844 from yebblies/issue10369 Issue 10369 - Deprecate unordered floating point comparisons -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11727] Repeated error message with using forward referenced enum as variable
https://d.puremagic.com/issues/show_bug.cgi?id=11727 --- Comment #5 from github-bugzi...@puremagic.com 2013-12-12 20:27:43 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/65d3e9019f1f06a436ff3f8d922d63df7bc7479b fix Issue 11727 - Repeated error message with using forward referenced enum as variable https://github.com/D-Programming-Language/dmd/commit/a5ae10d83cef074c93e25c174b3d80536eae700a Merge pull request #2956 from 9rnsr/fix11727 [diag] Issue 11727 - Repeated error message with using forward referenced enum as variable -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11727] Repeated error message with using forward referenced enum as variable
https://d.puremagic.com/issues/show_bug.cgi?id=11727
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2013-12-12 20:31:15 PST ---
Now the OP code:
auto returnEnum()
{
enum n;
return n; // Line 4
}
void main()
{
assert(returnEnum() == 0);
}
Prints:
test.d(4): Error: type n has no value
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11732] Ternary operator type unification problems with dstrings
https://d.puremagic.com/issues/show_bug.cgi?id=11732 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2013-12-13 18:00:06 EST --- First one is similar to issue 9968. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11733] Refuse int indexing of associative arrays with char keys
https://d.puremagic.com/issues/show_bug.cgi?id=11733 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2013-12-13 18:01:55 EST --- Why? 0 implicitly converts to both char and dchar. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11722] Qualifier-only casts should not invoke opCast
https://d.puremagic.com/issues/show_bug.cgi?id=11722 --- Comment #5 from monarchdo...@gmail.com 2013-12-12 23:34:46 PST --- (In reply to comment #0) This is a spin-off issue from bug 5747. D has a cast syntax for modifying just only the type qualifier of the operand. http://dlang.org/expression#CastExpression CastExpression: cast ( Type ) UnaryExpression cast ( CastQual ) UnaryExpression -- cast ( ) UnaryExpression-- Kenji: I'm wondering: Your original post seemed to imply the enhancement was *only* for qualifier cast. However, the final result seems to be for *any* kind of cast, whith matching types. I mean: const(S) s; auto a = cast() s; auto b = cast(S) s; In the case of a: We have a CastQual type cast, and this bypasses the opCast operator entirelly. In the case of b: We have a *Type* cast, but that happens to result only in a qualifier change. In the case of b, *should* we call opCast? Please clarify. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5747] cannot cast away shared if opCast defined
https://d.puremagic.com/issues/show_bug.cgi?id=5747
--- Comment #10 from monarchdo...@gmail.com 2013-12-12 23:35:57 PST ---
(In reply to comment #9)
(In reply to comment #7)
Your example snippet still overflows for me for the initial use case:
It doesn't with dmd 2.064.
Are you sure you don't mean HEAD? Head is the only version for me that doesn't
horribly die for me.
~/D$ ./HEAD/dmd/src/dmd -run main.d
~/D$ ./RELEASE/dmd.2.064.2/linux/bin64/dmd -run main.d
--- killed by signal 11
~/D$ ./RELEASE/dmd.2.064/linux/bin64/dmd -run main.d
--- killed by signal 11
~/D$ ./RELEASE/dmd.2.063.2/linux/bin64/dmd -run main.d
--- killed by signal 11
~/D$ ./RELEASE/dmd.2.063/linux/bin64/dmd -run main.d
--- killed by signal 11
But that's irrelevant. As I said, it is trivial to avoid recursion
If T is anything *but* const, I really don't see how you'd do anything
*other* than infinitely recurse.
T opCast(T)() const
if (is(Unqual!T == S))
{
static if (is(T == const))
return this;
else
//Not const: Try harder?
return cast(T)this;
}
contrary to your claim that it is impossible.
It *might* be possible (which is still yet to be proven), but it isn't
tirivial.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11722] Qualifier-only casts should not invoke opCast
https://d.puremagic.com/issues/show_bug.cgi?id=11722
--- Comment #6 from Kenji Hara k.hara...@gmail.com 2013-12-12 23:44:33 PST ---
(In reply to comment #5)
(In reply to comment #0)
This is a spin-off issue from bug 5747.
D has a cast syntax for modifying just only the type qualifier of the
operand.
http://dlang.org/expression#CastExpression
CastExpression:
cast ( Type ) UnaryExpression
cast ( CastQual ) UnaryExpression --
cast ( ) UnaryExpression--
Kenji: I'm wondering: Your original post seemed to imply the enhancement was
*only* for qualifier cast. However, the final result seems to be for *any*
kind
of cast, whith matching types. I mean:
const(S) s;
auto a = cast() s;
auto b = cast(S) s;
In the case of a: We have a CastQual type cast, and this bypasses the
opCast operator entirelly.
In the case of b: We have a *Type* cast, but that happens to result only in
a
qualifier change.
In the case of b, *should* we call opCast? Please clarify.
Yes.
And actually, with git-head, following code asserts only in the case of b.
struct S {
T opCast(T)() const { assert(0); }
}
void main()
{
const(S) s;
auto a = cast() s; // bypass opCast
auto b = cast(S) s; // call opCast and assert
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11722] Qualifier-only casts should not invoke opCast
https://d.puremagic.com/issues/show_bug.cgi?id=11722 --- Comment #7 from monarchdo...@gmail.com 2013-12-12 23:49:57 PST --- (In reply to comment #6) (In reply to comment #5) (In reply to comment #0) This is a spin-off issue from bug 5747. D has a cast syntax for modifying just only the type qualifier of the operand. http://dlang.org/expression#CastExpression CastExpression: cast ( Type ) UnaryExpression cast ( CastQual ) UnaryExpression -- cast ( ) UnaryExpression-- Kenji: I'm wondering: Your original post seemed to imply the enhancement was *only* for qualifier cast. However, the final result seems to be for *any* kind of cast, whith matching types. I mean: const(S) s; auto a = cast() s; auto b = cast(S) s; In the case of a: We have a CastQual type cast, and this bypasses the opCast operator entirelly. In the case of b: We have a *Type* cast, but that happens to result only in a qualifier change. In the case of b, *should* we call opCast? Please clarify. Yes. And actually, with git-head, following code asserts only in the case of b. Ah. Oops. I was testing the wrong code. Thanks. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
