[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #8 from Maxim Fomin ma...@maxim-fomin.ru 2013-10-09 23:19:45 PDT
---
(In reply to comment #6)
(In reply to comment #5)
Claim is follows: this is a D valid code.
OK.
Backing:
1) AGG(1) is a struct literal (struct spec page). Note, that struct literal
really means struct literal, not default struct constructor or implicit
function call or call expression or any other 'creative' understaning of
language rules.
2) Struct literal contains member initializers which should match in order
and
type to struct member initializer (struct spec page + TDPL).
3) Integer literal is valid initializer for static array of ints (TDPL).
How do you define is a valid initializer? The struct page
(http://dlang.org/struct.html ?) doesn't actually define it (nor does it
define
much on what is or isn't a valid construction type.
TDPL has explicit example in the beginning of fixed array chapter.
In my original case, S can be initialized by int, so isn't int a valid
initializer for S? If not, why not? Just because? This is what is throwing me
off.
struct S{int i;this(int){}}
struct AGG(T)
{
T t;
}
void main()
{
AGG!S ts2 = AGG!S(S(2)); //Explicit. Good.
AGG!S ts1 = AGG!S(1); //NO! ILLEGAL REQUEST FOR IMPLICIT CONSTRUCTION!
}
Second does not work because S(1) is not a struct literal but a constructor
call. AGG!S(1) initializer now would require function call S.__ctor(1) which is
not currently supported.
Seems the root argument is that static arrays are the *only* type that can be
initialized form a type that is not implicitly it, and that this special
rule
applies *only* during aggregate construction.
It seems you starting to understand the issue (but I haven't thought whether
static arrays are only types supporting this).
I see neither of the two points explained in struct.html, nor array.html ?
It is in TDPL. Anyway this feature was working for years.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #9 from Maxim Fomin ma...@maxim-fomin.ru 2013-10-09 23:31:12 PDT
---
(In reply to comment #7)
The inconsistency comes from the incomplete fix of bug 7019.
struct Agg(T) { T val; }
void main()
{
int[3] sa = 1;// 1a, OK
auto agg1 = Agg!(int[3])(1); // 1b, OK
struct S { this(int) {} }
S s = 1; // 2a, OK, by fixing issue 7019
auto agg2 = Agg!S(1); // 2b
}
Since long time ago, 1a and 1b has been allowed.
On the other hand, from 2.061, 2a has formally become a part of the language
spec, by fixing issue 7019.
However, currently 2b is still disallowed.
Formally this is right because struct initializers are not recursive. If
Add!int(1) is a valid struct literal doesn't mean that Agg!S(1) is also valid
because S(1) is valid (by the way, here you placed constructor not literal).
Unfortunately there is no implicit conversion between basic type to struct type
even if the latter is constructable from the former.
Because, when I had wrote a compiler patch for bug 7019, I had thought that
accepting it might cause some ambiguity on multi-dimentional array
initializing.
struct S { this(int) {} }
S[2][2] sa = [1, 2];
// exactly same as:
// sa = [[S(1), S(2)], [S(1), S(2)]]
// or: sa = [[S(1), S(1)], [S(2), S(2)]]
// ?
But recently, I found a new consistent rule to resolve the ambiguity. Based on
the rule in my brain, the 2b case would also be accepted.
Therefore, the current inconsistency is a bug to me. If T t = val; is
accepted,
the struct literal syntax Aggr!T(val) should also be accepted.
As I have mentioned previously, there is no inconsistency because you
implicitly assuming that struct literal/constructors can be recursive or
'nested' in some sense. If you mean allowing AGG!S ts1 = AGG!S(1); in original
example, then this is a minor enhancement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #10 from monarchdo...@gmail.com 2013-10-10 00:50:45 PDT ---
(In reply to comment #8)
It seems you starting to understand the issue (but I haven't thought whether
static arrays are only types supporting this).
OK. What about this...? Is it a bug?
//
struct S
{
int[1] arr;
}
void main()
{
uint[] udarr;
uint[1] usarr;
int[1] arr1 = udarr; //OK
int[1] arr2 = usarr; //OK
S s1 = S(udarr); //NOPE?
S s2 = S(usarr); //NOPE?
}
//
I'm not challenging you, I'm really just trying to understand the rules.
Anyway this feature was working for years.
I make no claim to the contrary. Original confusion comes from what I saw as
inconsistent, and made the upside down conclusion. I guess I should have
filed instead (maybe) that AGG!S(1) should be legal.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #11 from Kenji Hara k.hara...@gmail.com 2013-10-10 01:15:51 PDT
---
(In reply to comment #9)
As I have mentioned previously, there is no inconsistency because you
implicitly assuming that struct literal/constructors can be recursive or
'nested' in some sense. If you mean allowing AGG!S ts1 = AGG!S(1); in original
example, then this is a minor enhancement.
I knot that it is an enhancement (eg. bug 7255), but I think it's necessary to
increase consistency between static array and user-defined struct type, and
it's important for more expressiveness on initializing.
The start of my thought
Currently, BigInt accepts built-in integers as the valid initializer.
BigInt num = 1;
This is expressive syntax. But, when you declare a multi-dimensional array of
BigInt, it would become too verbose.
BigInt[128] sa = [
BigInt(1), BigInt(2), BigInt(3), BigInt(4),
BigInt(5), BigInt(6), BigInt(7), BigInt(8),
...
];
If T t = v; is allowed, array initializer should also allow T[n] tsa = [v1, v2,
...]; After the enhancement implemented, we will be able to write the BigInt
array declaration as:
BigInt[128] sa = [1, 2, 3, 4, 5, 6, 7, 8, ..., 128];
The end of my thought
I think we could apply the same rule to the relation of struct literal syntax
arguments and corresponding struct field type.
Agg!S agg = Agg!S(1); // #1
S[1] ssa = [1];// #2
- In #1, the struct field Agg!S.val is initialized by the corresponding value 1
which is in the struct literal argument list.
- In #2, the array element ssa[1] is initialized by the corresponding value 1
which is in the array initializer argument list.
In both case, if the initialized storage typed S accepts the corresponding
value 1 *as the valid initializer*, the composite array/struct initializing
should also work.
Additional note: The following code already works currently.
Agg!S aggr2 = {val:1}; // struct initializer syntax
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
Maxim Fomin ma...@maxim-fomin.ru changed:
What|Removed |Added
Keywords|accepts-invalid |
Severity|normal |enhancement
--- Comment #12 from Maxim Fomin ma...@maxim-fomin.ru 2013-10-10 01:32:06 PDT
---
(In reply to comment #11)
(In reply to comment #9)
As I have mentioned previously, there is no inconsistency because you
implicitly assuming that struct literal/constructors can be recursive or
'nested' in some sense. If you mean allowing AGG!S ts1 = AGG!S(1); in
original
example, then this is a minor enhancement.
I knot that it is an enhancement (eg. bug 7255), but I think it's necessary to
increase consistency between static array and user-defined struct type, and
it's important for more expressiveness on initializing.
The start of my thought
Currently, BigInt accepts built-in integers as the valid initializer.
BigInt num = 1;
This is expressive syntax. But, when you declare a multi-dimensional array of
BigInt, it would become too verbose.
BigInt[128] sa = [
BigInt(1), BigInt(2), BigInt(3), BigInt(4),
BigInt(5), BigInt(6), BigInt(7), BigInt(8),
...
];
If T t = v; is allowed, array initializer should also allow T[n] tsa = [v1,
v2,
...]; After the enhancement implemented, we will be able to write the BigInt
array declaration as:
BigInt[128] sa = [1, 2, 3, 4, 5, 6, 7, 8, ..., 128];
The end of my thought
OK. I agree that there is room for improving support for implicit construction.
I think we could apply the same rule to the relation of struct literal syntax
arguments and corresponding struct field type.
Agg!S agg = Agg!S(1); // #1
S[1] ssa = [1];// #2
It looks like when you are speaking about struct literal syntax you mean both
struct literal and struct constructors (probably even opCall). It seems that
Agg!S(1) would be valid either if there is constructor taking int or first
member is integer type. Do you consider documenting it after merging
corresponding pull?
- In #1, the struct field Agg!S.val is initialized by the corresponding value
1
which is in the struct literal argument list.
- In #2, the array element ssa[1] is initialized by the corresponding value 1
which is in the array initializer argument list.
In both case, if the initialized storage typed S accepts the corresponding
value 1 *as the valid initializer*, the composite array/struct initializing
should also work.
Additional note: The following code already works currently.
Agg!S aggr2 = {val:1}; // struct initializer syntax
OK. I changed type of the issue to show it is enhacement now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
Maxim Fomin ma...@maxim-fomin.ru changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #13 from Maxim Fomin ma...@maxim-fomin.ru 2013-10-10 01:46:55 PDT
---
(In reply to comment #10)
(In reply to comment #8)
It seems you starting to understand the issue (but I haven't thought whether
static arrays are only types supporting this).
OK. What about this...? Is it a bug?
//
struct S
{
int[1] arr;
}
void main()
{
uint[] udarr;
uint[1] usarr;
int[1] arr1 = udarr; //OK
int[1] arr2 = usarr; //OK
S s1 = S(udarr); //NOPE?
S s2 = S(usarr); //NOPE?
}
//
I'm not challenging you, I'm really just trying to understand the rules.
Integer arrays as initializers is completely different story. What you are
trying was not supported and not documented. However, what is more important is
that recently there was an enhacement request to support such conversions (I
don't know issue number) or something similar and consensus was to allow it
(probably there is a pull for it). Since Kenji is in thread he probably may
clarify the situation.
(In general this is currently a dark territory of language.)
Anyway this feature was working for years.
I make no claim to the contrary. Original confusion comes from what I saw as
inconsistent, and made the upside down conclusion. I guess I should have
filed instead (maybe) that AGG!S(1) should be legal.
OK, marked as rejects-valid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords|rejects-valid |
--- Comment #14 from Kenji Hara k.hara...@gmail.com 2013-10-10 02:00:57 PDT
---
(In reply to comment #12)
I think we could apply the same rule to the relation of struct literal
syntax
arguments and corresponding struct field type.
Agg!S agg = Agg!S(1); // #1
S[1] ssa = [1];// #2
It looks like when you are speaking about struct literal syntax you mean both
struct literal and struct constructors (probably even opCall). It seems that
Agg!S(1) would be valid either if there is constructor taking int or first
member is integer type. Do you consider documenting it after merging
corresponding pull?
No. I strictly distinguish struct literal and struct constructor call.
struct S1 { int num; }// S1(1) is literal syntax
struct S2 { this(int); } // S2(1) is ctor call
struct S3 { static S3 opCall(int); } // S3(1) is static function call
struct A1(T) { T val; }
struct A2(T) { this(T); }
void main()
{
S1 s1 = 1; // should be NG, int is not implicitly convertible to S1
S2 s2 = 1; // OK. The S2 ctor accepts int value as a valid initializer,
// then it's implicitly invoked for initialization.
S3 s3 = 1; // NG. opCall is completely unrelated to initializing.
// Note that A1!T(...) is always literal syntax
A1!S1 a11 = A1!S1(1); // NG, int is not implicitly convertible to S1
A1!S2 a12 = A1!S2(1); // should be OK, as same as the 's2' case.
A1!S3 a13 = A1!S3(1); // Of course NG.
// Note that A2!T(...) is constructor call
A2!S1 a21 = A2!S1(1); // NG, int is not implicitly convertible to S1
A2!S2 a22 = A2!S2(1); // NG, int is not implicitly convertible to S1
A2!S3 a23 = A2!S3(1); // NG, int is not implicitly convertible to S1
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
--- Comment #15 from Kenji Hara k.hara...@gmail.com 2013-10-10 02:21:30 PDT
---
(In reply to comment #10)
uint[] udarr;
uint[1] usarr;
int[1] arr1 = udarr; //OK
int[1] arr2 = usarr; //OK
Mmm...I think this is a bug. Because following code is also accepted in
compilation, and will cause runtime exception!
void main()
{
int[4] sa;
ulong[4] sa2 = sa;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11213] Simplify switch case-range statement
http://d.puremagic.com/issues/show_bug.cgi?id=11213 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #4 from monarchdo...@gmail.com 2013-10-10 02:23:23 PDT --- (In reply to comment #3) http://dlang.org/faq.html#case_range As written in the FAQ, it's intended syntax. As an enhancement, I don't see why case 0 : .. case 4 : couldn't also be: case 0 .. 5; If anything, case 0 .. 5 is more consistent with what the language does *everywhere*else*, and case 0 : .. case 4 : is the actual artifact that never should have existed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11215] New: `inout` lose enclosing `shared` on resolution
http://d.puremagic.com/issues/show_bug.cgi?id=11215 Summary: `inout` lose enclosing `shared` on resolution Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: wrong-code Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: verylonglogin@gmail.com --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-10-10 13:26:28 MSD --- E.g. `shared(inout(void)**)` is incorrectly resolved to `shared(qualifier(void))**`. --- shared(inout(void)**) f(inout int); static assert(is(typeof(f(0)) == shared(void**))); // fails static assert(is(typeof(f((const int).init)) == shared(const(void)**))); // fails --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11213] Simplify switch case-range statement
http://d.puremagic.com/issues/show_bug.cgi?id=11213 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #5 from bearophile_h...@eml.cc 2013-10-10 03:32:08 PDT --- (In reply to comment #4) As an enhancement, I don't see why case 0 : .. case 4 : couldn't also be: case 0 .. 5; If anything, case 0 .. 5 is more consistent with what the language does *everywhere*else*, and case 0 : .. case 4 : is the actual artifact that never should have existed. This introduces the problem that we'll need to solve adding [] to iota: iota So Kenji is right. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10763] (x)[0 .. 1] doesn't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=10763 --- Comment #12 from Iain Buclaw ibuc...@ubuntu.com 2013-10-10 04:26:12 PDT --- (In reply to comment #11) Don, I think I'm ready to test trial this in GDC if you are willing to implement this in DMD? Added support in GDC (but no front-end support) in case you want to go down this route. https://github.com/D-Programming-GDC/GDC/commit/262a5bd22754e0fa8176c1cef523bde33d1559df -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11210] -inline rejects valid code with captured AA
http://d.puremagic.com/issues/show_bug.cgi?id=11210 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-10-10 04:59:50 PDT --- *** This issue has been marked as a duplicate of issue 4841 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4841] -inline wrecks certain nested structs causing error *** is a nested function and cannot be accessed from ***
http://d.puremagic.com/issues/show_bug.cgi?id=4841 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||c...@benjamin-thaut.de --- Comment #20 from Kenji Hara k.hara...@gmail.com 2013-10-10 04:59:50 PDT --- *** Issue 11210 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 11204] Struct is destroyed before constructed
http://d.puremagic.com/issues/show_bug.cgi?id=11204 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-10-10 05:14:26 PDT --- *** This issue has been marked as a duplicate of issue 9665 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||samu...@voliacable.com --- Comment #19 from Kenji Hara k.hara...@gmail.com 2013-10-10 05:14:26 PDT --- *** Issue 11204 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 11216] New: Make synchronized statement `nothrow`
http://d.puremagic.com/issues/show_bug.cgi?id=11216
Summary: Make synchronized statement `nothrow`
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-10-10
17:09:20 MSD ---
Currently this code fails to compile because `_d_criticalenter` and
`_d_criticalexit` are not `nothrow`:
---
void f() nothrow
{ synchronized { } }
---
This is because user supplied monitor can throw as `lock`/`unlock` methods of
`Object.Monitor` are not `nothrow`.
Dependent druntime functions like `rt_attachDisposeEvent` and
`rt_detachDisposeEvent` are thus not `nothrow` too.
The proposal is to mark user supplied monitor `lock`/`unlock` methods also
`nothrow`. In the case it will be rejected documentation note about the fact
synchronized statement is not `nothrow` should be added.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11216] Make synchronized statement `nothrow`
http://d.puremagic.com/issues/show_bug.cgi?id=11216 --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com 2013-10-10 17:14:31 MSD --- Also in the case in the description are there any possibilities to supply a user monitor? If not, this subcase is clearly a rejects-valid bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11213] Simplify switch case-range statement
http://d.puremagic.com/issues/show_bug.cgi?id=11213 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-10 06:23:15 PDT --- I don't buy that argument. A switch statement is special enough that inclusive semantics for the right-hand side would not be confusing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11207] improve implicit conversions of function pointers/delegates
http://d.puremagic.com/issues/show_bug.cgi?id=11207 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-10 06:51:00 PDT --- *** This issue has been marked as a duplicate of issue 7725 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7725] Implicit function pointer cast
http://d.puremagic.com/issues/show_bug.cgi?id=7725 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||eberhardhoepf...@gmx.de --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-10-10 06:51:00 PDT --- *** Issue 11207 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 9665] Structure constant members can not be initialized if have opAssign
http://d.puremagic.com/issues/show_bug.cgi?id=9665 --- Comment #21 from Max Samukha samu...@voliacable.com 2013-10-10 07:10:42 PDT --- (In reply to comment #20) I see there was a discussion in bug 9665. - ignore this sentence. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11217] Header generation does not output 'inout' storage class on parameters
http://d.puremagic.com/issues/show_bug.cgi?id=11217 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-10-10 07:35:40 PDT --- https://github.com/D-Programming-Language/dmd/pull/2648 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11218] New: alias this and mixin templates should be interchangeable
http://d.puremagic.com/issues/show_bug.cgi?id=11218
Summary: alias this and mixin templates should be
interchangeable
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: eberhardhoepf...@gmx.de
--- Comment #0 from Eberhard eberhardhoepf...@gmx.de 2013-10-10 10:36:35 PDT
---
mixin templates and alias-this are really the same thing, the first being a
static mixin, the second a dynamic mixin. So I expect them to be
interchangeable:
import std.stdio;
mixin template T() {
void foo() { writeln(mixin); }
}
class C {
void foo() { writeln(mixin); }
}
class Outer {
void foo() { writeln(outer); }
class Inner {
static const bool TEMPLATE = true;
static if (TEMPLATE) {
mixin T;
} else {
C c = new C;
alias c this;
}
void test() {
foo();
}
}
void test() {
Inner i = new Inner;
i.test();
}
}
void main(string[] args) {
Outer o = new Outer;
o.test();
}
Output:
TEMPLATE == true: mixin
TEMPLATE == false: outer -- should be mixin!
I expect alias-this to behave like a mixin template:
class C {
void foo() {}
}
class Outer {
void foo() {}
static class Inner {
C c = new C;
alias c this;
void test() {
foo(); // Error
}
}
}
test.d(10): Error: this for foo needs to be type Outer not type
test.Outer.Inner
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11219] New: isExpression should work on non-type template instantiations
http://d.puremagic.com/issues/show_bug.cgi?id=11219
Summary: isExpression should work on non-type template
instantiations
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2013-10-10 10:55:34
PDT ---
Given a templated type:
struct Foo(int x) {
enum myValue = x;
}
I can check if something is an instantiation of this type:
template isFoo(T) {
enum isFoo = is(T == Foo!U, U...);
}
But when the template acts only as a namespace:
template Bar(T) {
enum myValue = x;
}
the isExpression recognizes Bar!T as not a type, and the comparisons return
false.
A useful idiom is to store compile-time values in such a template (typetuples
that don't auto-flatten, for instance), and later being able to tell if the
value being passed is an instantiation of template A or template B:
template Rectangle(float w, float h) {
enum values = TypeTuple!(w,h);
}
template Circle(float radius) {
enum values = TypeTuple!(radius);
}
template doStuff(alias A) {
// Behave differently for a rectangle than for a circle.
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11148] Can't implicitly convert const(BigInt) or immutable(BigInt) to BigInt
http://d.puremagic.com/issues/show_bug.cgi?id=11148 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #3 from hst...@quickfur.ath.cx 2013-10-10 11:15:45 PDT --- Is this really a bug? BigInt is implemented as a reference type, so allowing a cast from const(BigInt) to BigInt would be a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188
--- Comment #2 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net
2013-10-10 11:23:53 PDT ---
(In reply to comment #1)
Does std.math.abs even work for anything other than built-in types currently?
I
know it should, but I'm skeptical if it does.
It works for regular BigInt, it's just when you qualify that with shared, const
or immutable that it fails.
In any case, it should take inout arguments since it doesn't (and shouldn't)
modify them. So this (in theory) should work:
inout(Num) abs(Num)(inout(Num) x) if ( ... ) {
return (x = 0) ? x : -x;
}
I'll give that a go and if it works, send a patch to Phobos. Thanks for the
thought. Incidentally, shouldn't in be sufficient there for the input?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #1 from hst...@quickfur.ath.cx 2013-10-10 11:20:06 PDT ---
Does std.math.abs even work for anything other than built-in types currently? I
know it should, but I'm skeptical if it does.
In any case, it should take inout arguments since it doesn't (and shouldn't)
modify them. So this (in theory) should work:
inout(Num) abs(Num)(inout(Num) x) if ( ... ) {
return (x = 0) ? x : -x;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11148] Can't implicitly convert const(BigInt) or immutable(BigInt) to BigInt
http://d.puremagic.com/issues/show_bug.cgi?id=11148 --- Comment #4 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-10-10 11:27:44 PDT --- I think it's an issue that you can't pass an immutable(BigInt) to a function that accepts a BigInt as input. This makes it difficult to e.g. write generic functions that work with any integer type. I'm not sure what the appropriate way to deal with that is, though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188 --- Comment #3 from hst...@quickfur.ath.cx 2013-10-10 11:36:03 PDT --- (In reply to comment #2) I'll give that a go and if it works, send a patch to Phobos. Thanks for the thought. Incidentally, shouldn't in be sufficient there for the input? In this case, you need inout, because you want to propagate the incoming qualifiers to the output: if x=0, then you're returning x again, so the return type needs to carry whatever qualifiers x had on entering the function. Everything implicitly converts to const, of course, but it would suck if you returned const and the caller passed in unqual, and now after calling abs he can't modify the BigInt anymore! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11148] Can't implicitly convert const(BigInt) or immutable(BigInt) to BigInt
http://d.puremagic.com/issues/show_bug.cgi?id=11148 --- Comment #5 from hst...@quickfur.ath.cx 2013-10-10 11:39:18 PDT --- You can't pass an immutable(BigInt) to a function that takes unqual BigInt, because that breaks the type system (and risks breaking immutability). The function needs to take const(BigInt) if it doesn't need to propagate qualifiers to its return type, or inout(BigInt) if it does. If the function needs to modify the BigInt, then it should rightly reject any attempt to pass in an immutable BigInt. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188 --- Comment #4 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-10-10 11:47:51 PDT --- Tweaking std.math.abs to accept an inout input results in the following error when I added a regular BigInt to the unittests: assert(abs(BigInt(-234567)) == 234567); --- std/math.d(311): Error: function std.bigint.BigInt.opCmp (ref const(BigInt) y) const is not callable using argument types (int) inout std/math.d(311): Error: mutable method std.bigint.BigInt.opUnary!-.opUnary is not callable using a inout object std/math.d(341): Error: template instance std.math.abs!(BigInt) error instantiating --- So I'd guess in turn std.bigint.BigInt.opCmp (and other BigInt methods) ought to require (or at least have available) inout input. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11220] New: Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220
Summary: Regression in master: XXX__lambda2 cannot access frame
of function XXX
Product: D
Version: future
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: deadal...@gmail.com
--- Comment #0 from deadalnix deadal...@gmail.com 2013-10-10 12:23:42 PDT ---
auto lex(R)(R ) {
struct Lexer {
int t;
@property
auto front() {
return t;
}
}
auto lexer = Lexer();
return lexer;
}
auto flattenMixin() {
auto trange = lex('\0');
trange.parsePrimaryExpression();
}
void parsePrimaryExpression(R)(R trange) {
trange.parseAmbiguous!((parsed) {
trange.front;
});
}
typeof(handler(null)) parseAmbiguous(alias handler, R)(R trange) {
return handler(trange.parsePrimaryExpression());
}
Trying to compile this with DMD from master gives
src/d/semantic/declaration.d(24): Error: function
declaration.parsePrimaryExpression!(Lexer).parsePrimaryExpression.__lambda2!(typeof(null)).__lambda2
cannot access frame of function
declaration.parsePrimaryExpression!(Lexer).parsePrimaryExpression
This used to compile (this is a reduction of actual code in SDC).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220 deadalnix deadal...@gmail.com changed: What|Removed |Added Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6754] extern() in a function signature
http://d.puremagic.com/issues/show_bug.cgi?id=6754
--- Comment #4 from bearophile_h...@eml.cc 2013-10-10 13:26:36 PDT ---
Another example:
alias extern(C) void function() TF1; // OK
alias TF2 = extern(C) void function(); // Error
void main() {}
test.d(2): Error: basic type expected, not extern
test.d(2): Error: semicolon expected to close alias declaration
test.d(2): Error: no identifier for declarator extern (C) void function()
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11221] New: C-style struct literals in associative array literals too
http://d.puremagic.com/issues/show_bug.cgi?id=11221
Summary: C-style struct literals in associative array literals
too
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-10-10 14:04:33 PDT ---
struct MyStruct {
int x;
}
void main() {
MyStruct[string] aa1 = [A: MyStruct(1),
B: MyStruct(2),
C: MyStruct(3)]; // OK
MyStruct[string] aa2 = [A: {1}, B: {2}, C : {3}]; // Error
}
DMD 2.064 alpha gives:
test.d(8): Error: not an associative array initializer
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11222] New: std.string.isNumeric accepts a +
http://d.puremagic.com/issues/show_bug.cgi?id=11222
Summary: std.string.isNumeric accepts a +
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-10-10 14:06:51 PDT ---
With DMD 2.064 alpha this raises no assert error:
import std.string: isNumeric;
void main() {
assert(isNumeric(+));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10357] std.typecons.Nullable!(SysTime).Nullable.__ctor!() error instantiating
http://d.puremagic.com/issues/show_bug.cgi?id=10357 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 10441] Static libraries too big
http://d.puremagic.com/issues/show_bug.cgi?id=10441 Walter Bright bugzi...@digitalmars.com 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 10357] std.typecons.Nullable!(SysTime).Nullable.__ctor!() error instantiating
http://d.puremagic.com/issues/show_bug.cgi?id=10357 --- Comment #3 from github-bugzi...@puremagic.com 2013-10-10 15:07:06 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/55bc6fc1de30ab58b667c1a0e227f92208a0bece fix Issue 10357 - std.typecons.Nullable!(SysTime).Nullable.__ctor!() error instantiating Add a workaround until qualified postblit is properly implemented. https://github.com/D-Programming-Language/phobos/commit/e478ddef9e230c66f0d7992e5abf6151c4aea9e6 Merge pull request #1612 from 9rnsr/fix10357 [REG2.063] Issue 10357 - std.typecons.Nullable!(SysTime).Nullable.__ctor!() error instantiating -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10255] When creating lib files, dmd no longer splits module into multiple obj files
http://d.puremagic.com/issues/show_bug.cgi?id=10255 --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2013-10-10 15:48:32 PDT --- https://github.com/D-Programming-Language/dmd/pull/2651 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8524] Phobos cannot be compiled with -inline
http://d.puremagic.com/issues/show_bug.cgi?id=8524 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Keywords||ice Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Version|unspecified |D2 Resolution||WORKSFORME -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11148] Can't implicitly convert const(BigInt) or immutable(BigInt) to BigInt
http://d.puremagic.com/issues/show_bug.cgi?id=11148 Brad Roberts bra...@puremagic.com changed: What|Removed |Added CC||bra...@puremagic.com --- Comment #7 from Brad Roberts bra...@puremagic.com 2013-10-10 16:28:11 PDT --- BigInt must behave essentially exactly like every other integral type (except for having a larger range of possible values), which includes being a value type. Any internal COW implementation must be invisible to users. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11188] std.math.abs fails for shared, const or immutable BigInt types
http://d.puremagic.com/issues/show_bug.cgi?id=11188 --- Comment #5 from Joseph Rushton Wakeling joseph.wakel...@webdrake.net 2013-10-10 17:33:40 PDT --- (In reply to comment #3) In this case, you need inout, because you want to propagate the incoming qualifiers to the output: if x=0, then you're returning x again, so the return type needs to carry whatever qualifiers x had on entering the function. Everything implicitly converts to const, of course, but it would suck if you returned const and the caller passed in unqual, and now after calling abs he can't modify the BigInt anymore! I wasn't talking about returning const, but about the _input_ to the function. I'm not actually certain you do always want to propagate the qualifiers to the output -- I may want to be able to do: immutable BigInt x = -345678; BigInt xAbs = abs(x); ... or is inout sensitive to things like this? In any case, bear in mind that abs doesn't always guaranteed to return the same type -- if you give it (say) a cfloat or an ifloat, it'll return a real. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-10-10 18:26:27 PDT ---
Slightly verified test case.
1. Remove UFCS in order to compile the code by using old compiler.
2. Add dummy return type 'int' to parsePrimaryExpression function.
Compilation succeeds until 2.059. but with 2.060 and later, it causes cannot
access frame of function error.
auto lex(R)(R ) {
struct Lexer {
int t;
@property
auto front() { return t; }
}
auto lexer = Lexer();
return lexer;
}
auto flattenMixin() {
auto trange = lex('\0');
parsePrimaryExpression(trange);
}
int parsePrimaryExpression(R)(R trange) {
parseAmbiguous!(/*delegate*/(parsed) {
trange.front;
})(trange);
return 1;
}
typeof(handler(null)) parseAmbiguous(alias handler, R)(R trange) {
return handler(parsePrimaryExpression(trange));
}
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220 --- Comment #2 from deadalnix deadal...@gmail.com 2013-10-10 18:32:06 PDT --- This is surprising because I'm working with 2.063.2 . I guess I'm somehow being lucky. It may be dependant on the compilation order or the way things are spread accross modules. Anyway, this is quite a showstopper. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220
--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2013-10-10
20:05:50 PDT ---
Even smaller test case:
struct Lexer {
int x;
}
int parsePrimaryExpression(Lexer trange) {
parseAmbiguous!( (parsed){ trange.x += 1; } )(trange);
return 1;
}
typeof(handler(null)) parseAmbiguous(alias handler)(Lexer trange) {
return handler(parsePrimaryExpression(trange));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220
--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2013-10-10
20:39:04 PDT ---
And smaller still:
int parsePrimaryExpression(int x) {
parseAmbiguous!( (parsed){ x += 1; } )();
return 1;
}
typeof(handler(1)) parseAmbiguous(alias handler)() {
return handler(parsePrimaryExpression(1));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-10-10 20:41:53 PDT --- The trouble is in the typeof(handler(1)). The type is void, but the compiler instantiates the template handler along the way, and handler needs a frame pointer, and doesn't have one, hence the error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11223] New: inline ice with tuple assignment and if/else
http://d.puremagic.com/issues/show_bug.cgi?id=11223
Summary: inline ice with tuple assignment and if/else
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P4
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: c...@dawg.eu
--- Comment #0 from Martin Nowak c...@dawg.eu 2013-10-10 21:23:13 PDT ---
cat bug.d CODE
struct Tuple(T...)
{
T values;
void opAssign(Tuple rhs)
{
if (0)
values = rhs.values;
else
assert(0);
}
}
void bug()
{
Tuple!string tmp;
tmp = Tuple!string();
}
CODE
dmd -c -inline bug
glue.c:1265: virtual unsigned int Type::totym(): Assertion `0' failed.
I reduced that test case from the vibe.d source code. The ICE is triggered by
the opAssign in std.typecons.Tuple so this might affects a lot of code and
fixing the regression is very important.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220
--- Comment #6 from Walter Bright bugzi...@digitalmars.com 2013-10-10
21:29:11 PDT ---
If I write it this way:
int parsePrimaryExpression(int x) {
parseAmbiguous!( (parsed){ x += 1; } )();
return 1;
}
template parseAmbiguous(alias handler)
{
typeof(handler(1))
//void
parseAmbiguous() {
return handler(1);
}
}
We can see that instantiating handler(1) outside the function parseAmbiguous()
is what causes the error, because it needs the frame of parseAmbiguous().
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #7 from Kenji Hara k.hara...@gmail.com 2013-10-10 21:36:35 PDT --- https://github.com/D-Programming-Language/dmd/pull/2652 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11220] Regression in master: XXX__lambda2 cannot access frame of function XXX
http://d.puremagic.com/issues/show_bug.cgi?id=11220 --- Comment #8 from Walter Bright bugzi...@digitalmars.com 2013-10-10 21:56:11 PDT --- (In reply to comment #7) https://github.com/D-Programming-Language/dmd/pull/2652 It's sure a pleasure working with you, Kenji! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
