[Issue 3659] Too much exegesis on opEquals

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3659



--- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2009-12-31 
07:37:33 PST ---
(In reply to comment #2)
 Here is the issue.  The compiler now is required to generate an opEquals which
 calls x.m == y.m on all members m of the struct (this was to fix bug 3433). 
 However, in order for this opEquals to handle const and immutable versions of
 the struct, the opEquals generated needs to be const.  Given that, if member m
 is another struct with a *user defined* opEquals, that opEquals must *also* be
 const.

I see, thanks for explaining.

 The current rule is too strict, I agree.  For instance, you should not require
 that the argument be ref const if the argument type can be implicitly cast 
 from
 const to mutable (i.e. a pure value type), but if the argument is ref, it
 *should* be const, and the opEquals function itself *should* be const. 
 Otherwise, you could be changing stuff just by doing a comparison.
 
 What is the use case for an opEquals not being const?

I'm thinking of our current stance on const: if you don't care about const,
don't use it and for the most part it won't intrude on you. For example,
string's use of immutability is fairly confined.

opEquals is a stark deviation from the stance above. It *will* intrude. The
classic example is this:

class Widget {
bool opEquals(Widget);
}

Compiling this issues:

Warning: object.Object.opEquals(Object o) is hidden by Widget

It only gets downhill from there:

struct Widget {
bool opEquals(Widget) { return true; }
}

This time it's an error:

Error: function test.Widget.opEquals type signature should be const bool(ref
const(Widget)) not bool(ref Widget)

So you simply can't not care about const. But then it's all getting viral
because cons is viral. Consider the user grudgingly agrees to add const, and
then...

class Widget {
private Gadget g;
bool opEquals(const Widget rhs) {
return compatibleGadgets(g, rhs.g);
}
}

But now it's still not fine because compatibleGadgets is also written without
caring about const. It's all a mess. 

Now consider that the user capitulates and decides to use const wherever
applicable. Things will still not work in certain cases. For example if
opEquals must compare members that are lazily computed, you can't make it
compile. Cheating by casting away const will mess up a variety of assumptions.

As an aside, I know what it takes to define lazily computed state to work with
const, but Walter is at the bottom of a 5000 TeV potential hole that spells
like this is like C++ mutable and C++ mutable is incorrect, therefore I will
not process any information henceforth. So I am unable to even start
explaining that to him. Besides, assuming Walter is convinced of the
correctness of the feature, it's unclear whether it will pull its weight. It
will complicate the language, and the benefits, while there, are rather subtle.

So I don't know what to do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3659] Too much exegesis on opEquals

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3659



--- Comment #4 from Steven Schveighoffer schvei...@yahoo.com 2009-12-31 
09:45:21 PST ---
(In reply to comment #3)
 I'm thinking of our current stance on const: if you don't care about const,
 don't use it and for the most part it won't intrude on you. For example,
 string's use of immutability is fairly confined.

Well, that wasn't the case not too long ago.  For example, all std.string
functions used strings as args, making doing simple things like searching for
substrings in mutable strings impossible.  I think if we work harder, we may
find some acceptable middle ground.

 opEquals is a stark deviation from the stance above. It *will* intrude. The
 classic example is this:
 
 class Widget {
 bool opEquals(Widget);
 }

Structs and classes are different stories.  A class is always passed by
reference, so I think it must always be const as an argument to an opEquals. 
This goes with my assertion above.  The counter-argument to having opEquals not
be const on Object is then you cannot compare 2 const objects without defining
separate functions.

 
 So you simply can't not care about const. But then it's all getting viral
 because cons is viral. Consider the user grudgingly agrees to add const, and
 then...
 
 class Widget {
 private Gadget g;
 bool opEquals(const Widget rhs) {
 return compatibleGadgets(g, rhs.g);
 }
 }
 
 But now it's still not fine because compatibleGadgets is also written without
 caring about const. It's all a mess. 

There is no way around it.  Const is viral, and in order to guarantee what it
does, it has to be.  The proposed inout helps in regards to not making things
const when they don't have to be, but at some point, the compiler has to either
give in (i.e. C++ mutable) or put its foot down.

Have you considered the other alternative that you didn't copy in reply:

Another alternative is to allow any signature for opEquals on type T, but then
any type U which has a member of type T will be illegal to compare unless type
U also defines opEquals.

I think this is a reasonable compromise, and doesn't require const signatures. 
The thing I don't like about the current solution is it requires a certain
signature even if you *never* include it as a member of another aggregate, just
in case the compiler has to write an opEquals around it.

 Now consider that the user capitulates and decides to use const wherever
 applicable. Things will still not work in certain cases. For example if
 opEquals must compare members that are lazily computed, you can't make it
 compile. Cheating by casting away const will mess up a variety of assumptions.
 
 As an aside, I know what it takes to define lazily computed state to work with
 const, but Walter is at the bottom of a 5000 TeV potential hole that spells
 like this is like C++ mutable and C++ mutable is incorrect, therefore I will
 not process any information henceforth. So I am unable to even start
 explaining that to him. Besides, assuming Walter is convinced of the
 correctness of the feature, it's unclear whether it will pull its weight. It
 will complicate the language, and the benefits, while there, are rather 
 subtle.

This is logical const all over again :)  Note that I think this is possibly the
only use case for opEquals not being const.  To compare 2 items and have them
visibly change is against any expectation I've ever had.  But this doesn't mean
we need to remove const from the signature, it just means we need to find a way
to make logical const work.  I remember arguing this with Janice a while back,
Walter never participated, and you were MIA.

Is there a possible library solution?  i.e. something like:

private mutable!(Gadget) g;

Where g is always mutable, no matter what it's container's mutability (i.e.
contain the dangerous const casts to a library type).  I'm sure there are some
template wizards out there who can make this happen, especially with opDispatch
now :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 282] Bizarre circular import nested name invisibility issue

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=282


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #7 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:09:22 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 400] forward reference error; no propety X for type Y (struct within struct)

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=400


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:10:01 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 1160] enums can not be forward referenced

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1160


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:10:28 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 1564] Forward reference error for enum in circular import

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1564


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:10:55 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 2029] Typesafe variadic functions don't work in CTFE

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2029


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #14 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:11:17 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3587] Aggregate rule references undefined Tuple

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3587


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:13:24 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3575] CTFE: member structs not initialized correctly

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3575


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:12:24 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3588] WithStatement rule references unspecified Symbol

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3588


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:13:40 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3591] TemplateIdentifier rule is misspelled

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3591


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:14:42 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 2816] Sudden-death static assert is not very useful

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=2816



--- Comment #13 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:11:36 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3455] Some Unicode characters not allowed in identifiers

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3455


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:11:58 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3584] DeclDef rule is missing entries

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3584


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:12:45 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3585] Duplicate clauses in EqualExpression and RelExpression rules

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3585


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:13:07 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3589] BaseClassList and InterfaceClasses rules are incorrect, missing ', '

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3589


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:14:01 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3592] ClassTemplateDeclaration and FunctionTemplateDeclaration rules are unreferenced

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3592


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:15:00 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3590] FunctionParameterList rule is missing

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3590


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:14:23 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3593] IntegerExpression rule unspecified

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3593


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:15:21 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3594] AsmPrimaryExp rule references unspecified rules

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3594


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:15:43 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3595] Several rules are missing ':' after rule name

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3595


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:16:00 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3611] Enum forward referencing regression

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3611


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:16:40 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3270] pure functions returning struct

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3270


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:18:57 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3601] Debug and Release builds of DMD produce different object files

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3601


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:16:20 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3612] ExpressionList is undefined

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3612


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:17:07 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3645] manifest constant (enum) crashes dmd

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3645


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:18:08 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3633] Optimizer causes access violation

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3633


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:17:47 PST ---
Fixed dmd 1.054 and 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3458] int fsync(int) commented out in core.sys.posix.unistd

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3458


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:19:44 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3476] C-style initializer for structs must be disallowed for structs with a constructor

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3476


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:20:02 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3514] opApply should be the first-choice foreach iteration method.

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3514


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED


--- Comment #10 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:20:21 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3596] Need alias for using std.algorithm.remove

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3596


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:21:16 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3621] implicit conversion to const rules need tightening

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3621



--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:21:33 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3577] Wrong precedence for opPow

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3577


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:20:41 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3583


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #5 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:20:59 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3647] non-function opDispatch crashes dmd

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3647


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:23:01 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3641] alias shared T U does not work

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3641


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution||FIXED


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2009-12-31 
11:22:42 PST ---
Fixed dmd 2.038

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3455] Some Unicode characters not allowed in identifiers

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3455


Ali Cehreli acehr...@yahoo.com changed:

   What|Removed |Added

 CC||acehr...@yahoo.com


--- Comment #6 from Ali Cehreli acehr...@yahoo.com 2009-12-31 16:04:07 PST ---
(In reply to comment #3)
 there is little interest in writing the code itself in unicode.
 There's a growing consensus that code should be written in ascii,
 for a long list of reasons.

Thank you very much for allowing us to program in UTF-8. There is a yet-to-grow
Turkish D community out there who have tremendous joy in being able to program
in Turkish.

I may be in the minority here, but UTF-8 identifiers has been the most
important feature for me to consider D.

Ali

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3660] New: Templates and shared functions don't mix

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3660

   Summary: Templates and shared functions don't mix
   Product: D
   Version: 2.036
  Platform: x86
OS/Version: Linux
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jason.james.ho...@gmail.com


--- Comment #0 from Jason House jason.james.ho...@gmail.com 2009-12-31 
19:27:50 PST ---
Sample code:

=
struct foo{
  void bar(T)(T t){}
  void bar(T)(T t) shared {}
}
void main(){
  foo x;
  x.bar(1);
}
=

Result with dmd 2.037:
$ dmd test.d
test.d(7): Error: template test.foo.bar(T) matches more than one function
template declaration:
  bar(T)
and:
  bar(T)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---


[Issue 3661] opPow not supported in array operations.

2009-12-31 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3661


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don clugd...@yahoo.com.au 2009-12-31 23:08:16 PST ---
(In reply to comment #0)
 This is agains 2.037.
 btw. also this in opPow doesnt work
 
  float pi = 3.14;
  float x = pi ^^ 2.0;
 
 one needs explicitly write 2.0f (this is because std.math.pow have only one F
 template parameter, and compiler doesn't know which to infer).

This works in 2.038.  Please ignore opPow in 2.037, it wasn't intended to be
complete. Perform all tests on 2.038.

As for the other ones -- opPow for array operations, where the exponent is not
a compile-time constant, will probably never be supported.
We could manage things like z[] = x^^2 + y^^2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---