[Issue 7717] Regression(2.059): typeof(this) incorrect in mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2012-03-16 01:36:31 PDT --- It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field -- so then init would change. .init is defined only when all possible members of the aggregate have been declared. Can you come up with a valid example? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7717] Regression(2.059): typeof(this) incorrect in mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=7717 timon.g...@gmx.ch changed: What|Removed |Added CC||timon.g...@gmx.ch --- Comment #2 from timon.g...@gmx.ch 2012-03-16 03:08:17 PDT --- (In reply to comment #1) It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field It does not add an extra field. -- so then init would change. If I added some random character to a valid d program, then it would likely not be valid anymore. What does this prove? .init is defined only when all possible members of the aggregate have been declared. This is the case in the example. What should be illegal is adding a field that changes .init based on a static condition that depends on .init. This would be part of a necessary general overhaul of symbol lookup works in DMD: Forward declarations and compile-time reflection make it possible to write contradictory or ambiguous D programs. The compiler should detect such setups in the least conservative way we can come up with. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6178] Struct inside the AA are not init correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6178 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #8 from hst...@quickfur.ath.cx 2012-03-16 08:10:42 PDT --- I think he meant -O, not -0. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7717] Regression(2.059): typeof(this) incorrect in mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=7717 --- Comment #3 from Vladimir Panteleev thecybersha...@gmail.com 2012-03-16 08:44:28 PDT --- If this behavior is invalid by design, then the error message should be improved (e.g. to .init not known at this point or recursive semantic analysis attempt on S). The workaround is to use std.traits.hasMember (which, underneath, uses __traits(allMembers, T)). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7717] Regression(2.059): typeof(this) incorrect in mixin template
http://d.puremagic.com/issues/show_bug.cgi?id=7717 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2012-03-16 09:03:39 PDT --- then the error message should be improved Never mind, the check is inside an is() condition - so AFAIU any errors should be silenced. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7718] New: regex and ctRegex produce different results
http://d.puremagic.com/issues/show_bug.cgi?id=7718
Summary: regex and ctRegex produce different results
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: jm.nie...@gmail.com
--- Comment #0 from Joshua Niehus jm.nie...@gmail.com 2012-03-16 09:01:21 PDT
---
The following snippet produce different matches when they should be the same.
#!/usr/local/bin/rdmd
import std.stdio, std.regex;
void main() {
string strcmd = ./myApp.rb -os OSX -path \/GIT/Ruby Apps/sec\ -conf 'no
timer';
auto ctre = ctRegex!(`(.*)|('.*')`, g);
auto re = regex (`(.*)|('.*')`, g);
auto ctm = match(strcmd, ctre);
foreach(ct; ctm)
writeln(ct.hit());
auto m = match(strcmd, re);
foreach(h; m)
writeln(h.hit());
}
/* output */
/GIT/Ruby Apps/sec
'no timer'
/GIT/Ruby Apps/sec
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6547] Call to std.algorithm.remove causes compile error
http://d.puremagic.com/issues/show_bug.cgi?id=6547 Tim Keating itsallaboutthe...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #3 from Tim Keating itsallaboutthe...@gmail.com 2012-03-16 12:26:44 PDT --- The minimal use case described by Yuri above still occurs with 2.058. If this isn't supposed to work for narrow strings, then perhaps a template specialization for the unsupported types that raises a useful error message is the right solution here? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5689] [64-Bit] uniform() fails with -profile
http://d.puremagic.com/issues/show_bug.cgi?id=5689 d...@dawgfoto.de changed: What|Removed |Added Keywords||pull --- Comment #6 from d...@dawgfoto.de 2012-03-16 13:24:14 PDT --- https://github.com/D-Programming-Language/druntime/pull/180 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7719] New: enum forward reference error when enum is in braces
http://d.puremagic.com/issues/show_bug.cgi?id=7719
Summary: enum forward reference error when enum is in braces
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-03-16
16:06:18 PDT ---
enum foo = bar;
enum {
bar = 1
}
void main() { }
test.d(3): Error: undefined identifier bar
Yet this works ok:
enum foo = bar;
enum bar = 1;
void main() { }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7719] enum forward reference error when enum is in braces
http://d.puremagic.com/issues/show_bug.cgi?id=7719
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-03-16
17:13:03 PDT ---
There are more issues with these enums inside of brackets. Right now I'm having
the weirdest errors where referencing these enums doesn't work from a class
defined below it:
enum
{
wxUSER_ATTENTION_INFO = 1,
wxUSER_ATTENTION_ERROR = 2,
}
If they're each defined separately:
enum wxUSER_ATTENTION_INFO = 1;
enum wxUSER_ATTENTION_ERROR = 2;
then it works. I don't have a minimal test-case for this now (working on it),
but there's obviously some issues with the implementation.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7670] UFCS problem with @property and structs
http://d.puremagic.com/issues/show_bug.cgi?id=7670
--- Comment #2 from bearophile_h...@eml.cc 2012-03-16 18:44:11 PDT ---
Maybe you have gone a bit too much far with your fix, Kenji Hara.
In my example code here I used @property:
@property ref double y(ref A a) {
But your patch allows that syntax even without @property.
Your patch allows _very_ nice and noise-free code like:
[1, 2, -3, 4].filter!(x = x 0).map!(x = x ^^ 0.2).writeln;
But I think it undermines the meaning and usefulness of the -property compiler
switch and the meaning of @property.
So I suggest to think a bit more about this, to keep the nice things, and to
not throw away two baby waters.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
