[Issue 3661] opPow not supported in array operations.
http://d.puremagic.com/issues/show_bug.cgi?id=3661 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 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: ---
[Issue 3661] New: opPow not supported in array operations.
http://d.puremagic.com/issues/show_bug.cgi?id=3661
Summary: opPow not supported in array operations.
Product: D
Version: 2.036
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bary...@smp.if.uj.edu.pl
--- Comment #0 from Witold Baryluk 2009-12-31
20:48:57 PST ---
This is agains 2.037.
void main() {
float[2] a,b,c;
a = [8.33, 7.11];
b = [2.1, 3.1];
double[2] d = [2.11, 3.11];
int[2] e = [4,5];
double[2] f;
// this should work
//c[] = a[] ^^ b[]; // Error: float[] ^^ float[] is not supported
//f[] = d[] ^^ d[]; // Error: double[] ^^ double[] is not supported
// just like
c[] = a[] * c[]; // works
// if possible this also
//c[] = 2.0f ^^ b[]; // Error: float ^^ float[] is not supported
//c[] = a[] ^^ 2.0f; // Error: float[] ^^ float is not supported
//f[] = d[] ^^ 2.0; // Error: double[] ^^ double is not supported
//f[] = 2.0 ^^ d[]; // Error: double ^^ double[] is not supported
// and then this also (relevant opPow is working).
//c[] = a[] ^^ e[]; // Error: float[] ^^ int[] is not supported
//f[] = d[] ^^ e[]; // Error: double[] ^^ int[] is not supported
//c[] = a[] ^^ 2; // Error: float[] ^^ int is not supported
//f[] = d[] ^^ 2; // Error: double[] ^^ int is not supported
// and eventually this also, but this part involves mixed types,
// and there is no opPow(double,float)
//c[] = 2.0 ^^ b[]; // Error: double ^^ float[] is not supported
//f[] = d[] ^^ a[]; // Error: double[] ^^ float[] is not supported
// or opPow(float,double),
//f[] = a[] ^^ 2.0; // Error: float[] ^^ double is not supported
//f[] = a[] ^^ d[]; // Error: float[] ^^ double[] is not supported
// similary this doesnt work currently
//c[] = a[] * d[]; // Error: incompatible types for ((a[]) * (e[])):
'float[]' and 'double[]'
//c[] = a[] * e[]; // Error: incompatible types for ((a[]) * (e[])):
'float[]' and 'int[]'
}
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).
--
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
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 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 3455] Some Unicode characters not allowed in identifiers
http://d.puremagic.com/issues/show_bug.cgi?id=3455 Ali Cehreli changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #6 from Ali Cehreli 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 3647] non-function opDispatch crashes dmd
http://d.puremagic.com/issues/show_bug.cgi?id=3647 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright 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 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright 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 3641] alias shared T U does not work
http://d.puremagic.com/issues/show_bug.cgi?id=3641 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3577] Wrong precedence for opPow
http://d.puremagic.com/issues/show_bug.cgi?id=3577 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright 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 3621] implicit conversion to const rules need tightening
http://d.puremagic.com/issues/show_bug.cgi?id=3621 --- Comment #4 from Walter Bright 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 3514] opApply should be the first-choice foreach iteration method.
http://d.puremagic.com/issues/show_bug.cgi?id=3514 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #10 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=3596 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright 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 3476] C-style initializer for structs must be disallowed for structs with a constructor
http://d.puremagic.com/issues/show_bug.cgi?id=3476 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3458] int fsync(int) commented out in core.sys.posix.unistd
http://d.puremagic.com/issues/show_bug.cgi?id=3458 Walter Bright changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright 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 3628] can't cast null to int
http://d.puremagic.com/issues/show_bug.cgi?id=3628 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 2009-12-31 11:18:33 PST --- Fixed dmd 1.054 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3617] CTFE: wrong code for if(x) where x is int or smaller
http://d.puremagic.com/issues/show_bug.cgi?id=3617 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 2009-12-31 11:17: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 3633] Optimizer causes access violation
http://d.puremagic.com/issues/show_bug.cgi?id=3633 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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 3443] Thread.thread_needLock() should be nothrow
http://d.puremagic.com/issues/show_bug.cgi?id=3443 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #6 from Walter Bright 2009-12-31 11:19:20 PST --- Fixed dmd 2.038 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3612] ExpressionList is undefined
http://d.puremagic.com/issues/show_bug.cgi?id=3612 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=3645 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Walter Bright 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 3601] Debug and Release builds of DMD produce different object files
http://d.puremagic.com/issues/show_bug.cgi?id=3601 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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 3270] pure functions returning struct
http://d.puremagic.com/issues/show_bug.cgi?id=3270 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Walter Bright 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 3611] Enum forward referencing regression
http://d.puremagic.com/issues/show_bug.cgi?id=3611 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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 3595] Several rules are missing ':' after rule name
http://d.puremagic.com/issues/show_bug.cgi?id=3595 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3594] AsmPrimaryExp rule references unspecified rules
http://d.puremagic.com/issues/show_bug.cgi?id=3594 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3593] IntegerExpression rule unspecified
http://d.puremagic.com/issues/show_bug.cgi?id=3593 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3590] FunctionParameterList rule is missing
http://d.puremagic.com/issues/show_bug.cgi?id=3590 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3589] BaseClassList and InterfaceClasses rules are incorrect, missing ', '
http://d.puremagic.com/issues/show_bug.cgi?id=3589 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=3592 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3585] Duplicate clauses in EqualExpression and RelExpression rules
http://d.puremagic.com/issues/show_bug.cgi?id=3585 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3584] DeclDef rule is missing entries
http://d.puremagic.com/issues/show_bug.cgi?id=3584 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3455] Some Unicode characters not allowed in identifiers
http://d.puremagic.com/issues/show_bug.cgi?id=3455 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Walter Bright 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 2816] Sudden-death static assert is not very useful
http://d.puremagic.com/issues/show_bug.cgi?id=2816 --- Comment #13 from Walter Bright 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 3588] WithStatement rule references unspecified Symbol
http://d.puremagic.com/issues/show_bug.cgi?id=3588 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=3591 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright 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 3587] Aggregate rule references undefined Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=3587 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=3575 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Walter Bright 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 1160] enums can not be forward referenced
http://d.puremagic.com/issues/show_bug.cgi?id=1160 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Walter Bright 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
http://d.puremagic.com/issues/show_bug.cgi?id=1564 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 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 400] forward reference error; no propety X for type Y (struct within struct)
http://d.puremagic.com/issues/show_bug.cgi?id=400 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Walter Bright 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 390] Cannot forward reference enum nested in struct
http://d.puremagic.com/issues/show_bug.cgi?id=390 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 2009-12-31 11:09:39 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 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Walter Bright 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 3659] Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659
--- Comment #4 from Steven Schveighoffer 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 3659] Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659
--- Comment #3 from Andrei Alexandrescu 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
http://d.puremagic.com/issues/show_bug.cgi?id=3659 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer 2009-12-31 05:51:24 PST --- 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. 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? 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
