[Issue 5115] std.typecons.scoped problems
http://d.puremagic.com/issues/show_bug.cgi?id=5115
--- Comment #9 from Kenji Hara 2011-11-10 23:11:38 PST ---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something
> like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
>
> It is fine for the temporary to be converted to Foo, so long as the destructor
> is called when the scope that 'scoped' was called in is exited.
Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"
But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe,
because the temporary has value type and its lifetime is limited in its scope,
but Foo is class reference of the temporary and we can bring it out the scope.
Foo global_foo;
void test1() {
auto foo = scoped!Foo();
global_foo = foo; // implicitly conversion from typeof(foo) to Foo
// This line should be forbidden in compile time
}
void test2() {
// use global_foo -> Access Violation!
}
void main() {
test1();
test2();
}
I think my ProxyOf mixin template is useful for this issue.
https://github.com/D-Programming-Language/phobos/pull/300
--- Comment #10 from Kenji Hara 2011-11-10 23:11:39 PST
---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something
> like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
>
> It is fine for the temporary to be converted to Foo, so long as the destructor
> is called when the scope that 'scoped' was called in is exited.
Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"
But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe,
because the temporary has value type and its lifetime is limited in its scope,
but Foo is class reference of the temporary and we can bring it out the scope.
Foo global_foo;
void test1() {
auto foo = scoped!Foo();
global_foo = foo; // implicitly conversion from typeof(foo) to Foo
// This line should be forbidden in compile time
}
void test2() {
// use global_foo -> Access Violation!
}
void main() {
test1();
test2();
}
I think my ProxyOf mixin template is useful for this issue.
https://github.com/D-Programming-Language/phobos/pull/300
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5115] std.typecons.scoped problems
http://d.puremagic.com/issues/show_bug.cgi?id=5115
--- Comment #9 from Kenji Hara 2011-11-10 23:11:38 PST ---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something
> like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
>
> It is fine for the temporary to be converted to Foo, so long as the destructor
> is called when the scope that 'scoped' was called in is exited.
Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"
But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe,
because the temporary has value type and its lifetime is limited in its scope,
but Foo is class reference of the temporary and we can bring it out the scope.
Foo global_foo;
void test1() {
auto foo = scoped!Foo();
global_foo = foo; // implicitly conversion from typeof(foo) to Foo
// This line should be forbidden in compile time
}
void test2() {
// use global_foo -> Access Violation!
}
void main() {
test1();
test2();
}
I think my ProxyOf mixin template is useful for this issue.
https://github.com/D-Programming-Language/phobos/pull/300
--- Comment #10 from Kenji Hara 2011-11-10 23:11:39 PST
---
(In reply to comment #8)
> scoped!Foo() returns a temporary of type scoped!(Foo).Scoped (or something
> like
> that).
> This temporary is implicitly converted to Foo using alias this, but the
> temporary never has it's destructor called due to bug 3516, which means Foo's
> destructor is never called either.
>
> It is fine for the temporary to be converted to Foo, so long as the destructor
> is called when the scope that 'scoped' was called in is exited.
Now bug 3516 was fixed. Then comment#1 code prints two "Foo.dtor"
But allowing conversion from temporary type (e.g. Scoped!Foo) to Foo is unsafe,
because the temporary has value type and its lifetime is limited in its scope,
but Foo is class reference of the temporary and we can bring it out the scope.
Foo global_foo;
void test1() {
auto foo = scoped!Foo();
global_foo = foo; // implicitly conversion from typeof(foo) to Foo
// This line should be forbidden in compile time
}
void test2() {
// use global_foo -> Access Violation!
}
void main() {
test1();
test2();
}
I think my ProxyOf mixin template is useful for this issue.
https://github.com/D-Programming-Language/phobos/pull/300
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5311] Pure is broken when accessing globals / static data through instance reference
http://d.puremagic.com/issues/show_bug.cgi?id=5311 Kenji Hara changed: What|Removed |Added Keywords||patch Platform|Other |All OS/Version|Windows |All --- Comment #1 from Kenji Hara 2011-11-10 22:24:54 PST --- https://github.com/D-Programming-Language/dmd/pull/507 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6790] buildPath using std.path.curdir segfaults
http://d.puremagic.com/issues/show_bug.cgi?id=6790 --- Comment #1 from Jonathan Sternberg 2011-11-10 16:18:31 PST --- As of dmd 2.056, this now throws "core.exception.OutOfMemoryError". No recompilation was needed, but recompilation resulted in the same thing. This is probably some error in druntime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #14 from timon.g...@gmx.ch 2011-11-10 13:58:05 PST --- (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > You may be misunderstanding me. I agree this is a bug. I'll try to be > > > clearer: > > > > > > 1. inout(const(T)) should resolve to const(T) or immutable(T) upon exit > > > from > > > inout scope. That it resolves to const(T) right now is a bug. > > > > > > 2. immutable(T) and inout(T) can legally implicitly cast to > > > inout(const(T)). > > > This is an enhancement. > > > > Hm ok. I believe you are right for a possible interpretation of the language > > spec. It states that nothing converts implicitly to inout, that immutable > > and > > inout convert to const but it does not make any mention of what converts to > > inout const. Ergo it is contradictory and we are both right. > > > > But 1. is not worth fixing if 2. is not implemented, therefore the bugfix > > implies the enhancement. =) > > 2 can be forced with a cast. 1 cannot be worked around. 1. can be worked around fine in this particular case. Use inout(const(int)[]) for the return type. It will give const(int)[] instead of const(int[]) for inout=mutable but that is generally acceptable as those two types implicitly convert to each other. It will not work for classes though. The workaround is to use structs and implement the OO shenanigans oneself. Or to drop inout and use templates. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #13 from Steven Schveighoffer 2011-11-10 13:41:52 PST --- (In reply to comment #12) > (In reply to comment #11) > > You may be misunderstanding me. I agree this is a bug. I'll try to be > > clearer: > > > > 1. inout(const(T)) should resolve to const(T) or immutable(T) upon exit from > > inout scope. That it resolves to const(T) right now is a bug. > > > > 2. immutable(T) and inout(T) can legally implicitly cast to > > inout(const(T)). > > This is an enhancement. > > Hm ok. I believe you are right for a possible interpretation of the language > spec. It states that nothing converts implicitly to inout, that immutable and > inout convert to const but it does not make any mention of what converts to > inout const. Ergo it is contradictory and we are both right. > > But 1. is not worth fixing if 2. is not implemented, therefore the bugfix > implies the enhancement. =) 2 can be forced with a cast. 1 cannot be worked around. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #12 from timon.g...@gmx.ch 2011-11-10 13:33:33 PST --- (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > inout's primary focus is transferring the type modifier from the > > > arguments to > > > the return type. Merging it with a possible external immutable type is > > > secondary. > > > > > > I think inout(const(T)) should resolve as we've discussed. The > > > enhancement is > > > that immutable(T) and inout(T) should be implicitly castable to > > > inout(const(T)). > > > > See specification of inout: > > http://d-programming-language.org/function.html > > > > "The inout forms a wildcard that stands in for any of mutable, const or > > immutable. When the function is called, the inout of the return type is > > changed > > to whatever the mutable, const, or immutable status of the argument type to > > the > > parameter inout was." > > > > If inout(const(T)) is parsed as const(T) then the inout does not form a > > wildcard that can stand for immutable. Contradiction with the language > > specification. That is a bug. > > You may be misunderstanding me. I agree this is a bug. I'll try to be > clearer: > > 1. inout(const(T)) should resolve to const(T) or immutable(T) upon exit from > inout scope. That it resolves to const(T) right now is a bug. > > 2. immutable(T) and inout(T) can legally implicitly cast to inout(const(T)). > This is an enhancement. Hm ok. I believe you are right for a possible interpretation of the language spec. It states that nothing converts implicitly to inout, that immutable and inout convert to const but it does not make any mention of what converts to inout const. Ergo it is contradictory and we are both right. But 1. is not worth fixing if 2. is not implemented, therefore the bugfix implies the enhancement. =) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #11 from Steven Schveighoffer 2011-11-10 13:22:28 PST --- (In reply to comment #10) > (In reply to comment #9) > > inout's primary focus is transferring the type modifier from the arguments > > to > > the return type. Merging it with a possible external immutable type is > > secondary. > > > > I think inout(const(T)) should resolve as we've discussed. The enhancement > > is > > that immutable(T) and inout(T) should be implicitly castable to > > inout(const(T)). > > See specification of inout: > http://d-programming-language.org/function.html > > "The inout forms a wildcard that stands in for any of mutable, const or > immutable. When the function is called, the inout of the return type is > changed > to whatever the mutable, const, or immutable status of the argument type to > the > parameter inout was." > > If inout(const(T)) is parsed as const(T) then the inout does not form a > wildcard that can stand for immutable. Contradiction with the language > specification. That is a bug. You may be misunderstanding me. I agree this is a bug. I'll try to be clearer: 1. inout(const(T)) should resolve to const(T) or immutable(T) upon exit from inout scope. That it resolves to const(T) right now is a bug. 2. immutable(T) and inout(T) can legally implicitly cast to inout(const(T)). This is an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #10 from timon.g...@gmx.ch 2011-11-10 13:12:29 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #6)
> > > I think this issue is an enhancement.
> >
> > I strongly disagree. What qualifies it as an enhancement for you?
>
> It *is* an enhancement, because the common type can just as easily be const,
> and the code is still valid. You are asking for an incremental change to how
> inout works.
>
> > I am not saying that this has an enormous priority, but it definitely is a
> > bug
> > in my eyes. The inout qualifier has failed if there are cases where it could
> > work but does not.
>
> inout's primary focus is transferring the type modifier from the arguments to
> the return type. Merging it with a possible external immutable type is
> secondary.
>
> I think inout(const(T)) should resolve as we've discussed. The enhancement is
> that immutable(T) and inout(T) should be implicitly castable to
> inout(const(T)).
See specification of inout:
http://d-programming-language.org/function.html
"The inout forms a wildcard that stands in for any of mutable, const or
immutable. When the function is called, the inout of the return type is changed
to whatever the mutable, const, or immutable status of the argument type to the
parameter inout was."
If inout(const(T)) is parsed as const(T) then the inout does not form a
wildcard that can stand for immutable. Contradiction with the language
specification. That is a bug.
(The specification does not mention any odd special cases!)
> Those aspects were not envisioned when the feature was
> created, so it works as designed (provided the resolution of inout(const(T))
> > is fixed).
s/created/implemented/g
You are arguing that DMD is sorta the language specification. It is not. It is
a buggy implementation of the language specification and cannot be relied upon.
When inout was created there was only the spec. The implementation does not
live up to the spec. It does not matter whether or not the issue was known
while writing the spec for deciding whether or not a particular implementation
implements the specification.
As an analogy, consider this function:
Tour TSP(Graph g);
It's specification says: This function solves the traveling salesman problem in
polynomial time.
Now comes the poor guy who implements the function:
Tour TSP(Graph g){ /* approximate the optimal solution */ }
The guy who wrote the specification did not think about the fact that solving
TSP in polynomial time is hard. Does that make the approximate solution
correct? It does not.
Do you agree?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 --- Comment #6 from timon.g...@gmx.ch 2011-11-10 13:14:59 PST --- (In reply to comment #5) > (In reply to comment #4) > > If you disagree, with what part of the explanation do you disagree? > > No, I don't disagree your explanation. My only argument is that is *debatable* > thing. Apparently it is. :o) > > OK. I'll change my patch to make the combination of inout and const ambiguous > (== keep current behavior) in order to make room for improvement. Thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 --- Comment #5 from Kenji Hara 2011-11-10 13:10:16 PST --- (In reply to comment #4) > If you disagree, with what part of the explanation do you disagree? No, I don't disagree your explanation. My only argument is that is *debatable* thing. OK. I'll change my patch to make the combination of inout and const ambiguous (== keep current behavior) in order to make room for improvement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 --- Comment #4 from timon.g...@gmx.ch 2011-11-10 12:57:55 PST --- (In reply to comment #3) > From discussion in https://github.com/D-Programming-Language/dmd/pull/505 > > 1. inout + const of T should parse [1a] const(T) or [1b] inout(T)? > 2. or introduce new combined qualifier inout(const(T))? (see bug 6930) > > Current my patch have selected [1a] as the result. Parsing it as inout(T) or parsing it as const(T) is both wrong (and any of the two are an arbitrary choice). The 'definition' of inout is that it is whatever qualifier is on the input argument. Consider the type inout(const(T)) We can now make a case distinction: 1. inout == mutable => inout(const(T)) == const(T) 2. inout == const => inout(const(T)) == const(const(T)) == const(T) 3. inout == immutable => inout(const(T)) == immutable(const(T)) == immutable(T) Option 1. does not support the 3rd case, therefore it is wrong. Option 2. works as expected, therefore it is correct. I do not think there is a choice. (adding unnecessary special cases is the way to make a language ugly and complicated, see C++) If you disagree, with what part of the explanation do you disagree? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #9 from Steven Schveighoffer 2011-11-10 12:50:44 PST --- (In reply to comment #8) > (In reply to comment #6) > > I think this issue is an enhancement. > > I strongly disagree. What qualifies it as an enhancement for you? It *is* an enhancement, because the common type can just as easily be const, and the code is still valid. You are asking for an incremental change to how inout works. > I am not saying that this has an enormous priority, but it definitely is a bug > in my eyes. The inout qualifier has failed if there are cases where it could > work but does not. inout's primary focus is transferring the type modifier from the arguments to the return type. Merging it with a possible external immutable type is secondary. I think inout(const(T)) should resolve as we've discussed. The enhancement is that immutable(T) and inout(T) should be implicitly castable to inout(const(T)). Those aspects were not envisioned when the feature was created, so it works as designed (provided the resolution of inout(const(T)) is fixed). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 --- Comment #3 from Kenji Hara 2011-11-10 12:48:18 PST --- >From discussion in https://github.com/D-Programming-Language/dmd/pull/505 1. inout + const of T should parse [1a] const(T) or [1b] inout(T)? 2. or introduce new combined qualifier inout(const(T))? (see bug 6930) Current my patch have selected [1a] as the result. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #8 from timon.g...@gmx.ch 2011-11-10 12:39:59 PST ---
(In reply to comment #6)
> I think this issue is an enhancement.
I strongly disagree. What qualifies it as an enhancement for you?
>
> With current dmd implementation, the result type of an inout function has
> *always* four possibilities, they are mutable, const, and immutable, and
> inout.
>
> The implementation of this enhancement will restrict the possibilities.
>
> inout(const(T)) foo(...) { ... }
> // can return only const(T), immutable(T), or inout(const(T)).
>
> It seems to be usable a little, but I'm not seeing a use case of that.
I am not saying that this has an enormous priority, but it definitely is a bug
in my eyes. The inout qualifier has failed if there are cases where it could
work but does not.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #7 from Steven Schveighoffer 2011-11-10
12:38:04 PST ---
What it does is allow you to return data that is immutable, but is not part of
the input, and still have it be immutable after inout is resolved.
The example given isn't quite compelling, because the data is always being
created (even if hidden behind a secondary function).
However, this is a more solid use case:
immutable(int)[] n = [1,2,3];
inout(const(int))[] foo(inout(int)[] x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : n;
}
Without this, this cannot be an inout function. It's signature would be:
const(int)[] foo(const(int)[] x)
Although this is legal, it loses specificity in the case where an immutable is
passed in.
I'm not saying it's not an enhancement or that the benefit is huge, but it's
definitely an improvement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
Kenji Hara changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #6 from Kenji Hara 2011-11-10 12:22:18 PST ---
I think this issue is an enhancement.
With current dmd implementation, the result type of an inout function has
*always* four possibilities, they are mutable, const, and immutable, and inout.
The implementation of this enhancement will restrict the possibilities.
inout(const(T)) foo(...) { ... }
// can return only const(T), immutable(T), or inout(const(T)).
It seems to be usable a little, but I'm not seeing a use case of that.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #5 from Kenji Hara 2011-11-10 11:59:36 PST ---
(In reply to comment #0)
> inout(const(int[])) foo(inout(int[]) x){
> import std.random;
> bool condition = cast(bool)uniform(0,2);
> return condition ? x : new immutable(int[])(2);
> }
>
> (currently this code is still accepted because of issue 6912, but as soon as
> it
> is fixed this won't work anymore)
I think that the reason why this code works is bug 6922, not bug 6912.
Because bug 6922 parses inout(const(int[])) as inout(int[]).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 --- Comment #4 from timon.g...@gmx.ch 2011-11-10 11:42:45 PST --- (In reply to comment #3) > So let my try to understand what inout(const(T)) actually means. > > If inout resolves to mutable or const, this becomes const(T) > If inout resolves to immutable, this becomes immutable(T) > If inout resolves to inout (i.e. nested inout function), then it stays as > inout(const(T)) > > Is this correct? Those were my thoughts, yes. > > So what I think this boils down to is that inout(T) and immutable(T) should > implicitly cast to inout(const(T)), given the rules above. It sure seems > plausible. Yes, exactly. (That follows from inout(const(T)) being the combined type.) > > I think the same should be extended to inout(const(T))* and inout(const(T))[] > Good point. > I'd like Kenji to weigh in (added to CC). Does this affect the patch in bug > 6912? Yes it does, the patch for 6912 currently claims inout(const(T)) is const(T). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 Steven Schveighoffer changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #3 from Steven Schveighoffer 2011-11-10 11:36:41 PST --- So let my try to understand what inout(const(T)) actually means. If inout resolves to mutable or const, this becomes const(T) If inout resolves to immutable, this becomes immutable(T) If inout resolves to inout (i.e. nested inout function), then it stays as inout(const(T)) Is this correct? So what I think this boils down to is that inout(T) and immutable(T) should implicitly cast to inout(const(T)), given the rules above. It sure seems plausible. I think the same should be extended to inout(const(T))* and inout(const(T))[] I'd like Kenji to weigh in (added to CC). Does this affect the patch in bug 6912? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
--- Comment #2 from timon.g...@gmx.ch 2011-11-10 11:16:41 PST ---
(In reply to comment #1)
> I'm not seeing a good use case here.
>
> Can't you just do:
>
> return condition ? x : new inout(int[])(2);
Is this better?
immutable(int[]) bar(){
return new immutable(int[])(2);
}
inout(const(int[])) foo(inout(int[]) x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : bar();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6930] combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer 2011-11-10 11:13:29 PST --- I'm not seeing a good use case here. Can't you just do: return condition ? x : new inout(int[])(2); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6930] New: combined type of immutable(T) and inout(T) should be inout(const(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6930
Summary: combined type of immutable(T) and inout(T) should be
inout(const(T))
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-11-10 11:00:59 PST ---
The combined type of immutable(T) and inout(T) should be inout(const(T)).
For example:
inout(const(int[])) foo(inout(int[]) x){
import std.random;
bool condition = cast(bool)uniform(0,2);
return condition ? x : new immutable(int[])(2);
}
(currently this code is still accepted because of issue 6912, but as soon as it
is fixed this won't work anymore)
DMD 2.056 says that the combined type of immutable(T) and inout(T) is const(T),
but that is losing information.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6929] New: [ICE] typeMerge crashes in presence of ambiguous alias this conversions
http://d.puremagic.com/issues/show_bug.cgi?id=6929
Summary: [ICE] typeMerge crashes in presence of ambiguous alias
this conversions
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-11-10 08:29:45 PST ---
T t;
S s;
struct S{
T get() const {return t;}
alias get this;
}
struct T{
S get() const {return s;}
alias get this;
}
static assert(is(typeof(1? t:s)));
Fails with:
dmd: cast.c:1908: int typeMerge(Scope*, Expression*, Type**, Expression**,
Expression**): Assertion `!(i1 && i2)' failed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6928] New: alias this, immutable and common type fail in presence of fields with indirections
http://d.puremagic.com/issues/show_bug.cgi?id=6928
Summary: alias this, immutable and common type fail in presence
of fields with indirections
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: timon.g...@gmx.ch
--- Comment #0 from timon.g...@gmx.ch 2011-11-10 08:24:28 PST ---
T x;
struct S{
T get() const {return x;}
alias get this;
}
struct T{int* p;} // p is necessary.
immutable(S) s;
immutable(T) t;
static assert(is(typeof(1? s:t))); // ok.
static assert(is(typeof(1? t:s))); // ok.
static assert(is(typeof(1? s:t)==typeof(1? t:s))); // fail.
void main(){
auto x = 1? t:s; // ok.
auto y = 1? s:t; // compile error.
}
The code should compile fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6912] const(T)[]/immutable(T)[] can be implicitly cast to inout(const(T)[])/inout(immutable(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=6912 --- Comment #6 from Steven Schveighoffer 2011-11-10 06:49:38 PST --- (In reply to comment #5) > (In reply to comment #4) > > I think this should be accepts-invalid, since the given example code should > > not > > compile. > > Wow, I'm sorry, and thank you for your fix. Don't worry about it! The main fix is the patch, my change was a nitpick :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6912] const(T)[]/immutable(T)[] can be implicitly cast to inout(const(T)[])/inout(immutable(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=6912 --- Comment #5 from Kenji Hara 2011-11-10 06:07:48 PST --- (In reply to comment #4) > I think this should be accepts-invalid, since the given example code should > not > compile. Wow, I'm sorry, and thank you for your fix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6912] const(T)[]/immutable(T)[] can be implicitly cast to inout(const(T)[])/inout(immutable(T)[])
http://d.puremagic.com/issues/show_bug.cgi?id=6912 Steven Schveighoffer changed: What|Removed |Added Keywords|rejects-valid |accepts-invalid --- Comment #4 from Steven Schveighoffer 2011-11-10 05:36:46 PST --- I think this should be accepts-invalid, since the given example code should not compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2486] taking address of slice rvalue is valid
http://d.puremagic.com/issues/show_bug.cgi?id=2486
Kenji Hara changed:
What|Removed |Added
Platform|x86 |All
Version|1.037 |D1 & D2
OS/Version|Linux |All
Severity|minor |normal
--- Comment #1 from Kenji Hara 2011-11-10 03:09:27 PST ---
This is still valid in D2.
import std.stdio;
void main()
{
int[] arr = [1,2,3];
auto p = &(arr[0..2]); // same as &(arr[0..2])
writeln(typeof(p).stringof);// int[]*
writeln(arr.ptr);
writeln(&arr);
writeln(p);
assert(&arr == p);
}
I think this is bad behavior, because it allows nonsense code like follows.
void main()
{
int[] arr = [1,2,3];
foo(arr[0..2]); // ref parameter can receive lvalue made by slicing
assert(arr == [1,2,3]); // assertion succeeds...
}
void foo(ref int[] arr)
{
arr = [4,5,6]; // what is modified?
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 Kenji Hara changed: What|Removed |Added CC||bugzi...@kyllingen.net --- Comment #1 from Kenji Hara 2011-11-10 01:42:21 PST --- *** Issue 6338 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6922] [TDPL] superimposing of const and immutable does not work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=6922 Kenji Hara changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #2 from Kenji Hara 2011-11-10 01:42:51 PST --- https://github.com/D-Programming-Language/dmd/pull/505 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6338] Immutability is lost for shared(immutable(T))
http://d.puremagic.com/issues/show_bug.cgi?id=6338 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Kenji Hara 2011-11-10 01:42:21 PST --- *** This issue has been marked as a duplicate of issue 6922 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
