[Issue 6255] Add support for different base conversions in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=6255 --- Comment #5 from github-bugzi...@puremagic.com 2012-01-25 23:55:44 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/42083000a43b569e1d368261678ebd140586ee73 Merge pull request #372 from 9rnsr/fix6255 Issue 6255 - Add support for different base conversions in std.conv -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6255] Add support for different base conversions in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=6255 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||FIXED --- Comment #6 from github-bugzi...@puremagic.com 2012-01-26 00:04:20 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/bd9596f9625a6d9a196388b7c18813ccaf3da470 Added Issue# 6255 to the changelog. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6255] Add support for different base conversions in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=6255 --- Comment #6 from github-bugzi...@puremagic.com 2012-01-26 00:04:20 PST --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/bd9596f9625a6d9a196388b7c18813ccaf3da470 Added Issue# 6255 to the changelog. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7234] Segmentation fault when using stdio
http://d.puremagic.com/issues/show_bug.cgi?id=7234
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don clugd...@yahoo.com.au 2012-01-26 00:15:08 PST ---
This seems to be the same as bug 7231.
It reduces to:
struct Bug7324 {
void opDispatch()(){}
}
void func7234()
{
Bug7234 r;
if (r.xxx) {};
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7295] Alias This + Pure + pointsTo = rejects-valid
http://d.puremagic.com/issues/show_bug.cgi?id=7295 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-01-26 00:45:17 PST --- https://github.com/D-Programming-Language/dmd/commit/2357f7771b7a5bdd560c2e8e9656d4194e8388d9 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7296] [2.058] Regression: Cannot swap RefCounted
http://d.puremagic.com/issues/show_bug.cgi?id=7296 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2012-01-26 00:45:34 PST --- https://github.com/D-Programming-Language/dmd/commit/2357f7771b7a5bdd560c2e8e9656d4194e8388d9 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7231] Segfault using opDispatch with property notation
http://d.puremagic.com/issues/show_bug.cgi?id=7231 --- Comment #1 from github-bugzi...@puremagic.com 2012-01-26 02:11:26 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f88878558c3066abed4f288c9dfa717427041be1 fix Issue 7231 - Segfault using opDispatch with property notation -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7231] Segfault using opDispatch with property notation
http://d.puremagic.com/issues/show_bug.cgi?id=7231 --- Comment #1 from github-bugzi...@puremagic.com 2012-01-26 02:11:26 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f88878558c3066abed4f288c9dfa717427041be1 fix Issue 7231 - Segfault using opDispatch with property notation --- Comment #2 from github-bugzi...@puremagic.com 2012-01-26 02:11:38 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4f0980fc1fef275d3dbb6994eefeea42e6e863f2 fix Issue 7231 - Segfault using opDispatch with property notation -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7231] Segfault using opDispatch with property notation
http://d.puremagic.com/issues/show_bug.cgi?id=7231 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from github-bugzi...@puremagic.com 2012-01-26 02:11:26 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f88878558c3066abed4f288c9dfa717427041be1 fix Issue 7231 - Segfault using opDispatch with property notation --- Comment #2 from github-bugzi...@puremagic.com 2012-01-26 02:11:38 PST --- Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/4f0980fc1fef275d3dbb6994eefeea42e6e863f2 fix Issue 7231 - Segfault using opDispatch with property notation -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7356] Implement KeyType, ValueType for hashes in std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=7356 --- Comment #5 from Kenji Hara k.hara...@gmail.com 2012-01-26 04:07:44 PST --- (In reply to comment #2) Some have Of, others don't. I don't see what Of adds, except verbosity. IMHO, it comes from the typeof() feature. First of all, and for fairness, `StringTypeOf` is the one that I added into Phobos in the past, so original XXXTypeOf is only FunctionTypeOf. I'm not a native English speaker, but it seems to me that XXXTypeOf!(Y) is more natural than XXXType!(Y). The former looks like a sentence, but latter like a noun. This kind of templates work like meta function, and function name usually contains verb. So I sometimes feel wrong about the latter. And, 'KeyType' and 'ValueType' are often used in user code. I think we should avoid using generic name as the piece of library, as far as possible. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-01-26 04:30:30 PST ---
My understanding is, each inout deduction from a function argument just like
pattern matching.
Parameter type: inout( int *)*
Argument type: mutable(immutable(int)*)* // mutable(...) is pseudo modifier
-- 'inout' is deduced to 'mutable'.
I think if we allow this kind of deduction, there is an ambiguous case:
inout(int) foo(inout(int**) x){ return 0; }
void main()
{
immutable(int*)* x;
foo(x);
// inout is deduced to imuutable or const? Both conversions
// immutable(int*)* to immutable(int**)
// immutable(int*)* to const(int**)
// are valid, so it is ambiguous.
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7371] New: Associative arrays as associative array keys
http://d.puremagic.com/issues/show_bug.cgi?id=7371
Summary: Associative arrays as associative array keys
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-01-26 04:52:07 PST ---
D2 code:
import std.stdio;
alias bool[int] IntSet;
void main() {
int[IntSet] aa;
aa[[1:true, 2:true]] = true;
IntSet is1 = [1:true];
is1[2] = true;
aa[is1] = 2;
writeln(aa);
}
Output:
[[1:true, 2:true]:1, [1:true, 2:true]:2]
Expected output:
[[1:true, 2:true]:2]
This bug is almost major.
Related to bug 3789 ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) nested function passed by alias to nested member function
http://d.puremagic.com/issues/show_bug.cgi?id=4504
--- Comment #10 from bearophile_h...@eml.cc 2012-01-26 04:54:36 PST ---
Same bug?
import std.algorithm: map;
void foo() {
map!(x = x)([1]);
}
void main() {
int opApply(int delegate(ref int) dg) {
int result;
foo();
result = dg(result);
if (result)
return result;
return result;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4504] ICE(toir.c) nested function passed by alias to nested member function
http://d.puremagic.com/issues/show_bug.cgi?id=4504
--- Comment #11 from bearophile_h...@eml.cc 2012-01-26 04:56:11 PST ---
Same bug?
import std.algorithm: map;
void foo() {
map!(x = x)([1]);
}
struct Bar {
int opApply(int delegate(ref int) dg) {
int result;
foo();
result = dg(result);
if (result)
return result;
return result;
}
}
void main() {}
DMD 2.058head:
test.d(6): Error: function test.Bar.opApply cannot get frame pointer to map
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5695] Problem with TypeTuple of lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=5695 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-01-26 05:05:10 PST --- With 2.058head (f8887855), that code works correctly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7321] returning void considered unsafe by safety inference
http://d.puremagic.com/issues/show_bug.cgi?id=7321 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch, rejects-valid --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-01-26 05:49:58 PST --- https://github.com/D-Programming-Language/dmd/pull/642 This is a shortfall of fixing bug 6902. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7160] Regression(2.057): ICE(dsymbol.c:1052) ICE using __traits(derivedMembers)
http://d.puremagic.com/issues/show_bug.cgi?id=7160 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||tob...@pankrath.net --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-01-26 05:59:45 PST --- *** Issue 7368 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 7368] template mixin + __traits(allMembers) = Assertion 'members' failed
http://d.puremagic.com/issues/show_bug.cgi?id=7368 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-01-26 05:59:44 PST --- Thanks for your reporting, but it was already fixed in git repo. Please wait the release of 2.058. *** This issue has been marked as a duplicate of issue 7160 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-01-26 06:24:43 PST --- Is this a dup of 4875? Recently Walter commented in that issue, and marked it WONTFIX. He said: Allowing such implicit conversions works in C++, but is considered a defect by experienced C++ professionals. We won't repeat the mistake. But he doesn't mention about the inconsistency. We need more discussion. Personally implicit constructor call on initializer is useful, e.g. BigInt. It is more better that can specify implicit or explicit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4149] refs displayed as pointers in gdb
http://d.puremagic.com/issues/show_bug.cgi?id=4149 Leandro Lucarella leandro.lucare...@sociomantic.com changed: What|Removed |Added CC||leandro.lucarella@sociomant ||ic.com --- Comment #12 from Leandro Lucarella leandro.lucare...@sociomantic.com 2012-01-26 07:04:10 PST --- (In reply to comment #6) I agree with Brad's comment 2. What's the relation between this and pull request 526[1] (commit e81dbc2 in dmd-1.x) that has been merged recently. At least according to the pull request, the improved usage of DWARF is only activated when -g is specified. Should that be changed for -gc? What about bug 3389? I think Robert's suggestion about having a -gd for D extensions and -g for standard debugging stuff would be better. Right now the situation with -g/-gc is far from ideal. [1] https://github.com/D-Programming-Language/dmd/pull/526 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355
Steven Schveighoffer schvei...@yahoo.com changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2012-01-26
07:56:53 PST ---
(In reply to comment #1)
My understanding is, each inout deduction from a function argument just like
pattern matching.
Parameter type: inout( int *)*
Argument type: mutable(immutable(int)*)* // mutable(...) is pseudo modifier
-- 'inout' is deduced to 'mutable'.
The compiler should either fail to match, since inout wildcard is not applying
to the immutable, or if it does match, it should treat foo as:
int** foo(int **x) { return x; }
This should fail to be able to be called with immutable(int)**.
The assert should fail because the typeof should resolve to Error.
I think this bug is invalid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7372] New: wrong error: undefined identifier
http://d.puremagic.com/issues/show_bug.cgi?id=7372
Summary: wrong error: undefined identifier
Product: D
Version: D1
Platform: x86
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: leandro.lucare...@sociomantic.com
--- Comment #0 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-01-26 08:50:37 PST ---
Test case:
m.d
---
import m2;
interface I {}
class C : I { mixin M!(I); }
---
m2.d
import m1;
template M (T)
{
public void f()
{
bug(1); // line 6
}
}
m1.d
template bug(T)
{
void bug(T t) {}
}
$ dmd -c m.d
m2.d(6): Error: undefined identifier bug
m2.d(6): Error: function expected before (), not __error of type _error_
Aside from the second spurious error, bug symbol should be perfectly defined.
Moving any template function to another module fixes the problem. Using a
selective import (import m1 : bug;) also fails. Using the full name of the
symbol (m1.bug(1); using static import m1; or without static) produces this
error instead:
m2.d(6): Error: undefined identifier m1, did you mean module m?
m2.d(6): Error: function expected before (), not __error of type _error_
Adding an alias to m2.d like this: alias m1.bug bug; fixes the problem. So it
looks like the symbol is hidden to the template.
A git bisect show this commit as the one introducing the regression:
merge D2 pull 591 (93a643aba6f62db1b7658c2bfb51f9d0b576c337)
https://github.com/D-Programming-Language/dmd/commit/93a643aba6f62db1b7658c2bfb51f9d0b576c337
https://github.com/D-Programming-Language/dmd/pull/591
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355
--- Comment #3 from timon.g...@gmx.ch 2012-01-26 09:07:23 PST ---
(In reply to comment #2)
(In reply to comment #1)
My understanding is, each inout deduction from a function argument just like
pattern matching.
Parameter type: inout( int *)*
Argument type: mutable(immutable(int)*)* // mutable(...) is pseudo
modifier
-- 'inout' is deduced to 'mutable'.
The compiler should either fail to match, since inout wildcard is not applying
to the immutable, or if it does match, it should treat foo as:
int** foo(int **x) { return x; }
This should fail to be able to be called with immutable(int)**.
The assert should fail because the typeof should resolve to Error.
I think this bug is invalid.
The typeof resolves to error because inout resolves to immutable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355
--- Comment #4 from timon.g...@gmx.ch 2012-01-26 09:20:32 PST ---
(In reply to comment #1)
My understanding is, each inout deduction from a function argument just like
pattern matching.
Parameter type: inout( int *)*
Argument type: mutable(immutable(int)*)* // mutable(...) is pseudo modifier
-- 'inout' is deduced to 'mutable'.
The compiler deduces inout to _immutable_ in this case. Other than that, it
does not make much sense to talk about a mutable pseudo modifier: inout is
transitive, but such a pseudo modifier cannot be transitive.
I think if we allow this kind of deduction, there is an ambiguous case:
inout(int) foo(inout(int**) x){ return 0; }
void main()
{
immutable(int*)* x;
foo(x);
// inout is deduced to imuutable or const? Both conversions
// immutable(int*)* to immutable(int**)
// immutable(int*)* to const(int**)
// are valid, so it is ambiguous.
}
The same ambiguity is already resolved at other points in the compiler:
inout(int) foo(inout(int) x, inout(int)* y){ return 0; }
void main(){
immutable(int)* y;
foo(1, y);
}
inout is resolved to const, even though immutable would be a far better choice.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355 --- Comment #5 from Steven Schveighoffer schvei...@yahoo.com 2012-01-26 09:36:01 PST --- (In reply to comment #3) The typeof resolves to error because inout resolves to immutable. As I said, it should fail to match or match mutable and fail to call. I'm not sure which is correct, but I feel either way that the assert should fail. If it's resolving to immutable, I think it's a bug, not because it's not passing, but because it's failing for the wrong reason. I think your expectations would be a violation of const. Let's assume inout did resolve to const for foo, and the function could be called: immutable int x = 5; immutable(int)* xp = x; immutable(int)** xpp = xp; const(int *)* y = foo(xpp); int z = 2; *y = z; // this should pass, since I can assign int* to const(int*). assert(*xp == 2); z = 3; assert(*xp == 3); // oops! changed data perceived as immutable! Is there an error in my example? I think it comes down to this: immutable(int *)* foo(immutable(int *)* x) // inout == immutable const(int *)* foo(const(int *)* x) // inout == const int ** foo( int ** x) // inout == mutable none of these can be called with immutable(int)** because there is no implicit cast to the parameter. I don't think const(immutable(int)*)* reduces to const(int *)*. This does take some mental effort, so I may have made a mistake :) I hate double pointers... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5695] Problem with TypeTuple of lambdas
http://d.puremagic.com/issues/show_bug.cgi?id=5695 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355 --- Comment #6 from timon.g...@gmx.ch 2012-01-26 09:55:37 PST --- (In reply to comment #5) (In reply to comment #3) The typeof resolves to error because inout resolves to immutable. As I said, it should fail to match or match mutable and fail to call. I'm not sure which is correct, but I feel either way that the assert should fail. If it's resolving to immutable, I think it's a bug, not because it's not passing, but because it's failing for the wrong reason. I think your expectations would be a violation of const. No. Let's assume inout did resolve to const for foo, and the function could be called: immutable int x = 5; immutable(int)* xp = x; immutable(int)** xpp = xp; const(int *)* y = foo(xpp); int z = 2; *y = z; // this should pass, since I can assign int* to const(int*). You cannot assign anything to const(int*), that is the point of const. assert(*xp == 2); z = 3; assert(*xp == 3); // oops! changed data perceived as immutable! Is there an error in my example? I think it comes down to this: immutable(int *)* foo(immutable(int *)* x) // inout == immutable const(int *)* foo(const(int *)* x) // inout == const int ** foo( int ** x) // inout == mutable none of these can be called with immutable(int)** because there is no implicit cast to the parameter. I don't think const(immutable(int)*)* reduces to const(int *)*. It does. The second version is callable with immutable(int)**. Not fixing this would mean there are cases where code duplication is more expressive than inout. This does take some mental effort, so I may have made a mistake :) I hate double pointers... We have: immutable(T) is a subtype of const(T). = immutable(int) : const(int) const(T*) : const(S*) iff const(T) : const(S) = const(immutable(int)*) : const(int*) const(T)* : const(S)* iff const(T) : const(S) = const(immutable(int)*)* : const(int*)* qed -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7355] inout incorrectly resolved if the same type has both mutable and immutable parts
http://d.puremagic.com/issues/show_bug.cgi?id=7355 --- Comment #7 from Steven Schveighoffer schvei...@yahoo.com 2012-01-26 10:21:28 PST --- (In reply to comment #6) (In reply to comment #5) Let's assume inout did resolve to const for foo, and the function could be called: immutable int x = 5; immutable(int)* xp = x; immutable(int)** xpp = xp; const(int *)* y = foo(xpp); int z = 2; *y = z; // this should pass, since I can assign int* to const(int*). You cannot assign anything to const(int*), that is the point of const. Oh yeah :) Stupid me, for some reason in my head this made sense because there was a mutable part. immutable(int *)* foo(immutable(int *)* x) // inout == immutable const(int *)* foo(const(int *)* x) // inout == const int ** foo( int ** x) // inout == mutable none of these can be called with immutable(int)** because there is no implicit cast to the parameter. I don't think const(immutable(int)*)* reduces to const(int *)*. It does. The second version is callable with immutable(int)**. Not fixing this would mean there are cases where code duplication is more expressive than inout. You are right. So we need to come up with some rules for inout as to how it matches. What about this idea? for each inout parameter, we try as a substitute in order: mutable, immutable, inout, const. See if the argument can be implicitly converted to the substituted parameter. If none of the possible substitutes can be implicitly converted to for a single parameter, the function fails to be called, and an error is generated inout cannot be resolved [for parameter x] If substitutes can be found for all of the inout parameters, and they all match (i.e. all mutable, all immutable, all inout or all const), then that is used as the substitute and the function is called. If substitutes are different (e.g. one is mutable, but another is immutable), then const is used as the substitute. The parameters are then re-checked to see that they all implicitly convert to the substituted const type. If this is not possible, an error is generated common inout substitute cannot be found. I think this should be as capable as duplicate functions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #2 from hst...@quickfur.ath.cx 2012-01-26 10:27:46 PST ---
This bug also happens without public for static ctors:
class A {
static {
int x;// this is OK, interpreted as static int x
this() { ... } // this is NOT OK, interpreted as non-static this()
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7364] Better Eponymous Template syntax
http://d.puremagic.com/issues/show_bug.cgi?id=7364 Nick Treleaven ntrel-pub...@yahoo.co.uk changed: What|Removed |Added CC||ntrel-pub...@yahoo.co.uk --- Comment #1 from Nick Treleaven ntrel-pub...@yahoo.co.uk 2012-01-26 10:27:10 PST --- Eponymous templates don't have to use 'alias', they can use an eponymous symbol like a variable or function. In these cases requiring an extra alias statement might not be desirable. So this request might not necessarily help all uses of eponymous templates. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7364] Better Eponymous Template syntax
http://d.puremagic.com/issues/show_bug.cgi?id=7364 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-26 10:31:36 PST --- I believe that all of the examples in TDPL use enum rather than alias. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 --- Comment #5 from Trass3r mrmoc...@gmx.de 2012-01-26 19:33:22 CET --- I vote for doing the opposite of C++ and introducing a @implicit tag for constructors that are to be used in the fashion I depicted. We really need an easy way to finely control implicit conversions. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #6 from Vladimir Panteleev thecybersha...@gmail.com 2012-01-26 10:39:05 PST --- (In reply to comment #5) I vote for doing the opposite of C++ and introducing a @implicit tag for constructors that are to be used in the fashion I depicted. If we had opImplicitCast (for implicit casting of this to another type), this could have been named opImplicitCast_r (for implicit casting of another type to typeof(this)). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7373] New: (Regression git) Renamed imports conflict with other implicitly imported symbols
http://d.puremagic.com/issues/show_bug.cgi?id=7373
Summary: (Regression git) Renamed imports conflict with other
implicitly imported symbols
Product: D
Version: D1
Platform: x86
OS/Version: Linux
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: leandro.lucare...@sociomantic.com
--- Comment #0 from Leandro Lucarella leandro.lucare...@sociomantic.com
2012-01-26 10:40:22 PST ---
This is how to reproduce the regression:
echo 'module m1; struct S {}' m1.d
echo 'module m2; struct S {}' m2.d
echo 'module m3; import m1; import S = m2; S.S s;' m3.d
dmd -c m3.d
This works without the fix, but with the fix I get this errors:
m3.d(1): Error: m1.S at m1.d(1) conflicts with m2 at m3.d(1)
m3.d(1): Error: no property 'S' for type 'S'
m3.d(1): Error: S.S is used as a type
m3.d(1): Error: variable m3.s voids have no value
The only important is the first one. If you change m3 like this it works again:
echo 'module m3; import m1; import X = m2; alias X S; S.S s;' m3.d
^ ^
A git bisect show this commit as the one introducing the regression:
merge D2 pull 591 (93a643aba6f62db1b7658c2bfb51f9d0b576c337)
https://github.com/D-Programming-Language/dmd/commit/93a643aba6f62db1b7658c2bfb51f9d0b576c337
https://github.com/D-Programming-Language/dmd/pull/591
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6738] Can't call templatized property function from within a struct/class method
http://d.puremagic.com/issues/show_bug.cgi?id=6738 --- Comment #3 from github-bugzi...@puremagic.com 2012-01-26 12:06:13 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1d4438f151143fcdcb807e257959dd1d588f9048 Issue 6738 - Can't call templatized property function from within a struct/class method -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 620] Can't use property syntax with a template function
http://d.puremagic.com/issues/show_bug.cgi?id=620 --- Comment #6 from github-bugzi...@puremagic.com 2012-01-26 12:06:20 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8bc639fb00cab9002b91a1d900ddd72f56f993a4 Merge pull request #280 from 9rnsr/propDispatch Issue 620 - Can't use property syntax with a template function -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6780] Templated global property functions do not work
http://d.puremagic.com/issues/show_bug.cgi?id=6780 --- Comment #2 from github-bugzi...@puremagic.com 2012-01-26 12:06:27 PST --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a08a5bb9394c3b46e3cca6bee1c90922bc0e9da2 Issue 6780 - Templated global property functions do not work -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7374] New: stdin.byLine() throws AssertError on empty input
http://d.puremagic.com/issues/show_bug.cgi?id=7374
Summary: stdin.byLine() throws AssertError on empty input
Product: D
Version: D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-01-26 12:16:45 PST ---
Here's the test program:
import std.stdio;
void main() {
foreach (line; stdin.byLine()) {
writeln(Got input line: , line);
}
}
When the program is run on an empty input (e.g., running 'echo -n | program' in
the shell, or hitting ctrl-D once the program starts up, or piping an empty
file to the program), an assertion fails:
core.exception.AssertError@/usr/include/d2/4.6/std/stdio.d(989): Bug in
File.readln
It appears that the problem is caused by one of two things:
(1) ByLine.empty() assuming that as long as a file is open it will have at
least 1 line, but this is not true when the input is 0 bytes.
(2) stdin.readln() returns null if the input has 0 bytes, instead of a line of
0 length (which is what it does at EOF if the input is *not* empty).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2012-01-26 12:28:27 PST --- Not a bug. Spec sez: The static in the static constructor declaration is not an attribute, it must appear immediately before the this -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7372] (Regression git) wrong error: undefined identifier
http://d.puremagic.com/issues/show_bug.cgi?id=7372 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2012-01-26 12:25:59 PST --- This is not a bug. From the spec: Unlike a template instantiation, a template mixin's body is evaluated within the scope where the mixin appears, not where the template declaration is defined. The default for imports is private, so m1.bug is not visible to m.C. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #4 from hst...@quickfur.ath.cx 2012-01-26 12:35:32 PST ---
So the right syntax is:
class A {
static {
...
static this() { ... }
...
}
}
?
Or alternatively
class A {
static { ... }
static this() { ... }
}
?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #5 from bearophile_h...@eml.cc 2012-01-26 13:41:06 PST ---
(In reply to comment #3)
Not a bug. Spec sez:
The static in the static constructor declaration is not an attribute, it must
appear immediately before the this
Then is it better for the compiler to give an compile-time error for code like
this? Is this material for a diagnostic enhancement request?
class A {
static {
this() { ... }
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7019] implicit constructors are inconsistently allowed
http://d.puremagic.com/issues/show_bug.cgi?id=7019
mail.mantis...@gmail.com changed:
What|Removed |Added
CC||mail.mantis...@gmail.com
--- Comment #7 from mail.mantis...@gmail.com 2012-01-26 13:55:55 PST ---
(In reply to comment #0)
Yes, I'm aware that alias this makes it possible to allow implicit
conversions,
but it can't solve everything, esp. if you need to modify the value before you
'save' it:
...
Why not aliasing this to set/get methods, e.g:
struct Foo(T) {
alias prop this;
this( in T value ) {
m_Prop = value;
}
@property:
T prop() const {
return m_Prop;
}
ref auto prop( in T value ) {
return(m_Prop = value, this);
}
private:
T m_Prop;
}
void bar(T)( in Foo!T foo ) {
writeln( cast(T)foo );
}
int main() {
Foo!int foo = 42;
bar( foo );
foo = 10;
bar( foo );
return 0;
}
Are there any problems I'm not aware of?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 620] Can't use property syntax with a template function
http://d.puremagic.com/issues/show_bug.cgi?id=620 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Version|0.175 |D1 --- Comment #7 from Walter Bright bugzi...@digitalmars.com 2012-01-26 17:12:27 PST --- Fixed for D2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6738] Can't call templatized property function from within a struct/class method
http://d.puremagic.com/issues/show_bug.cgi?id=6738 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6780] Templated global property functions do not work
http://d.puremagic.com/issues/show_bug.cgi?id=6780 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-01-26 17:19:02 PST --- I don't think there's anything wrong with the current setup. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
--- Comment #7 from hst...@quickfur.ath.cx 2012-01-26 17:44:20 PST ---
There's nothing technically wrong with it, but it's misleading. When you write:
class A {
int x;
this(int) { ... }
static {
int y;
this(uint) { ... }
}
}
It appears as though the second ctor is somehow static in some sense, yet it
is not, as the current semantics mean that you can hoist it out of the static
block and still retain the same meaning. Since that's the case, why not
prohibit it from being placed in a static block in the first place?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868
Jonathan M Davis jmdavisp...@gmx.com changed:
What|Removed |Added
CC||jmdavisp...@gmx.com
--- Comment #8 from Jonathan M Davis jmdavisp...@gmx.com 2012-01-26 17:50:01
PST ---
Invalid attributes are usually ignored in D rather than resulting in an error.
So, it's quite consistent that if static {} has no effect on a constructor, the
compiler wouldn't complain about you putting a constructor within the static
block. Now, whether it's _desirable_ that D function that way is another matter
- in general, IMHO it's definitely a negative that invalid attributes get
ignored rather than resulting in errors - but it's definitely consistent with
the rest of the language.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5868] static attribute ignored with public static {} blocks
http://d.puremagic.com/issues/show_bug.cgi?id=5868 --- Comment #9 from bearophile_h...@eml.cc 2012-01-26 18:07:08 PST --- (In reply to comment #7) There's nothing technically wrong with it, but it's misleading. I think here there's material for a diagnostic enhancement request. (In reply to comment #8) Invalid attributes are usually ignored in D rather than resulting in an error. And this is so wrong that it must change. I have zero doubts about this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
