[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 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 #8 from Maxim Fomin 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 #7 from Kenji Hara 2013-10-09 21:54:03 PDT ---
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.
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.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6014] rt_finalize Segmentation fault , dmd 2.053 on linux & freebsd
http://d.puremagic.com/issues/show_bug.cgi?id=6014 Martin Nowak changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #21 from Martin Nowak 2013-10-09 21:41:30 PDT --- https://github.com/D-Programming-Language/druntime/commit/7189e90005e156ea2e826a47d47ed0e97efc0286 -- 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 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #3 from Kenji Hara 2013-10-09 21:12:33 PDT --- > http://dlang.org/faq.html#case_range As written in the FAQ, it's intended syntax. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11214] New: Coverage report not output if not run from source dir
http://d.puremagic.com/issues/show_bug.cgi?id=11214 Summary: Coverage report not output if not run from source dir Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: l...@luismarques.eu --- Comment #0 from Lu�s Marques 2013-10-09 20:30:04 PDT --- A program compiled with DMD does not generate the code coverage report file if the program is not run from the same directory as the source file(s). For instance, this works: ~/test$ dmd -cov test.d && ./test ~/test$ ls *.lst test.lst This does not output the coverage listing: ~/test/sub$ dmd -cov test.d ~/test/sub$ cd .. ~/test$ ./sub/test.d ~/test$ find . -name '*.lst' ~/test$ This attempt at a workaround works, but produces unhelpful listing filenames: ~/test/sub2$ dmd -cov ../sub1/test.d -of../sub1/test ~/test/sub2$ ../sub1/test ~/test/sub2$ ls *.lst zsh: no matches found: *.lst ~/test/sub2$ find . -name '*.lst' ./..-sub1-test.lst -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11203] extern (C++) classes broken
http://d.puremagic.com/issues/show_bug.cgi?id=11203 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-09 20:14:48 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/526629d21dd6defa43c8ad95541e52d5f51eaf47 fix Issue 11203 - fixup #614 - disable finalization for extern(C++) classes - BlkAttr is already default initialized to BlkAttr.FINALIZE so we have to clear the bit for C++ classes. https://github.com/D-Programming-Language/druntime/commit/8bb49c5e184dec6479dc99dfaa61613594f80bda Merge pull request #633 from dawgfoto/fix11203 fix Issue 11203 -- 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 rswhi...@googlemail.com changed: What|Removed |Added CC||rswhi...@googlemail.com --- Comment #2 from rswhi...@googlemail.com 2013-10-09 16:51:03 PDT --- Did you read that? http://dlang.org/faq.html#case_range -- 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 --- Comment #1 from Andrej Mitrovic 2013-10-09 16:19:55 PDT --- And in fact every time I have to use a case-range statement I forget that we use this strange syntax, I always reach for "case 0 .. 4" but end up having a syntax error. Allowing it would be 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 11213] New: Simplify switch case-range statement
http://d.puremagic.com/issues/show_bug.cgi?id=11213
Summary: Simplify switch case-range statement
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2013-10-09
16:19:04 PDT ---
The current case-range syntax is rather awkward and verbose:
-
import std.stdio;
void main()
{
foreach (x; 0 .. 10)
{
switch (x)
{
case 0: .. case 4:
writeln("a");
break;
case 5: .. case 9:
writeln("b");
break;
default:
}
}
}
-
I suggest we allow the syntax "case 0 .. 4:", e.g.:
-
switch (x)
{
case 0 .. 4:
writeln("a");
break;
case 5 .. 9:
writeln("b");
break;
default:
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11108] `hasElaborateAssign` should check whether the type is assignable
http://d.puremagic.com/issues/show_bug.cgi?id=11108 Denis Shelomovskij 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 11206] static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206 --- Comment #6 from monarchdo...@gmail.com 2013-10-09 14:11:33 PDT --- (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. 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. 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. I see neither of the two points explained in struct.html, nor array.html ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11212] New: Use of uninitialized struct allowed 2
http://d.puremagic.com/issues/show_bug.cgi?id=11212
Summary: Use of uninitialized struct allowed 2
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha 2013-10-09 14:00:29
PDT ---
Related to issue 11211
struct S {
@disable this();
bool cted;
this(int x) {
cted = true;
}
void foo() {
assert(cted);
}
}
void bar(A a) {
a.s.foo();
}
class A {
S s;
this() {
bar(this); // shouldn't compile
s = S(1);
}
}
void main() {
auto a = new A;
}
Passing 'this' outside the constructor should be disallowed before structs with
disabled constructors are initialized.
I could go on with bug reports but it is obvious that there is no good solution
in the face of current compilation model.
--
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 #5 from Maxim Fomin 2013-10-09 13:33:42 PDT
---
Let's start from the basics.
import std.stdio;
struct AGG
{
int[1] t;
double d;
}
void main()
{
AGG tarr2 = AGG(1);
writeln(tarr2);
}
Claim is follows: this is a D valid code.
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).
You can either refute the backing or make contra point that although the code
is valid, it shouldn't be because the code is bad/wrong/unsafe (but I don't see
how you can convince that reasoning is wrong or the code is unsafe).
Before you write again about assignment, call expressions or implicit type
conversion, please note, that whether integeral expression is convertible to
struct, whether integer expression is convertible to static array in call
expression, whether is(int: int[10]) is true, all of this is irrelevant to the
initialization case.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11203] extern (C++) classes broken
http://d.puremagic.com/issues/show_bug.cgi?id=11203 Martin Nowak changed: What|Removed |Added Keywords||pull CC||c...@dawg.eu --- Comment #1 from Martin Nowak 2013-10-09 13:25:10 PDT --- The init data is fine, C++ classes are now allocated by the GC, but there was a bug that caused the GC to finalize them, even though they don't have a classinfo ptr. https://github.com/D-Programming-Language/druntime/pull/633 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11211] New: Use of uninitialized struct allowed in a subclass
http://d.puremagic.com/issues/show_bug.cgi?id=11211
Summary: Use of uninitialized struct allowed in a subclass
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha 2013-10-09 13:22:19
PDT ---
struct S {
@disable this();
bool cted;
this(int x) {
cted = true;
}
void foo() {
assert(cted);
}
}
class A {
S s;
this(int x) {
s = S(1);
}
}
class B : A {
this() {
s.foo(); // shouldn't compile
super(1);
}
}
void main() {
auto b = new B;
}
The base class constructor should have been called before the struct can be
accessed in the subclass.
--
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 #4 from monarchdo...@gmail.com 2013-10-09 13:03:47 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > I'm arguing that AGG should not be constructible taking a 1.
>
> That's clear, but if you want to break the language you need to consider
> writing to newsgroup. Silent language change based on some issue in bugzilla
> is
> evil.
Filing it in buzilla is the first step.
> > > Integer literal is a valid
> > > initializer for static array. Statement "AGG!S ts1 = AGG!S(1);" is
> > > rejected
> > > because (unfortunately) 1 is not convertible to struct.
> >
> > Yes, integer is a valid initializer for a static array, and it is also a
> > valid
> > initializer for a struct that holds an int.
>
> Right.
>
> >
> > However, 1 is not convertible to a struct,
>
> Right. It is sad fact but in this context it is irrelevant because in the
> example there is no conversion from 1 to struct, there is struct literal with
> partial initializer which match initializer for first field.
>
> > not is it convertible to a static array.
>
> Wrong. int[1] ai = 1; ai = 1; is fine with the language so far. However in
> this
> case we speak about struct initializer so having integer literal to be
> initializer for static integer array is sufficient.
That doesn't mean convertible. It just means constructible and assignable:
struct S
{
this(int);
void opAssign(int);
}
S s = 1; s = 1;
Does that mean int is convertible to S? it doesn't.
Also:
is(int : int[1]); //FALSE
Also:
void foo(int[1]);
void main()
{
foo(1); //HERE
}
Error: function foo (int[1]) is not callable using argument types (int)
> > AGG(1) should not compile, because 1 is not convertible to
> > typeof(AGG.tupleof[0]);
>
> Please refer to the spec or argue if spec is incomplete for a particular case.
> Making up rules is not good. Adressing your point - this is incorrect because
> typeof(AGG.tupleof[0]) has type int[1] and initializaing or assigning 1 to
> int[1] is legal in D. I deliberatly unwrapped all templates to show that you
> are effectivelly protesting against int[1] = 1;
I will indeed lookup the exact spec. Please let me sleep on it. Do they make
any mention about special behavior for static arrays?
> > What's happening is an implicit *construction* of a static array, in a
> > context
> > where implicit construction is not allowed.
>
> This is not the case. Here is struct literal with partial list of initializers
> which match respective type initializers which is fine as far D is concern.
Except the type "int" doesn't match nor is convertible to the type "int[1]"
int[1] *can* be *initialized* from an int, yes. But so can a struct. Yet doing
the same for a struct that is both constructible and assignable doesn't work
(as I believe the spec says it shouldn't).
> If
> you are complaining because this breaks some assumption of a brilliant phobos
> ideom, this should be mentioned explicitly so some solution without damaging
> language can be found (personally I object to break the language for the sake
> of writing cute template in phobos).
That's definitely not the reason. However, that piece of code "shows" that
static arrays get a special treatment, that I do not believe they should get.
> Please don't reopen issue: CLOSED->REOPENED->CLOSED war is not good either.
Works for me if you agree to rebuke my points and prove me wrong :)
--
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 Benjamin Thaut changed: What|Removed |Added CC||c...@benjamin-thaut.de --- Comment #1 from Benjamin Thaut 2013-10-09 12:44:10 PDT --- This is most likely a duplicate of: http://d.puremagic.com/issues/show_bug.cgi?id=8360 -- 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 --- Comment #1 from Benjamin Thaut 2013-10-09 12:35:04 PDT --- The error message is: Error: function D main is a nested function and cannot be accessed from std.format.formatRange!(LockingTextW riter, MapResult!(__lambda2, SplitterResult!(isWhite, string)), char).formatRange -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11210] New: -inline rejects valid code with captured AA
http://d.puremagic.com/issues/show_bug.cgi?id=11210
Summary: -inline rejects valid code with captured AA
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: c...@benjamin-thaut.de
--- Comment #0 from Benjamin Thaut 2013-10-09 12:33:20
PDT ---
Dmd rejects the following valid code as soon as it is compiled with -inline
import std.stdio;
import std.range;
import std.algorithm : map;
import std.string;
import std.typecons;
void main(string[] args)
{
auto content = "one two three";
uint[string] counts;
auto result = splitter(content)
.map!(a => tuple(a, counts[a]));
writefln("%s", result);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11208] New: returned ref to scoped isn't caught by local ref escape error
http://d.puremagic.com/issues/show_bug.cgi?id=11208
Summary: returned ref to scoped isn't caught by local ref
escape error
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: e...@gnuk.net
--- Comment #0 from Brad Anderson 2013-10-09 10:02:20 PDT ---
Tested with dmd 2.63.2. Trying to return a ref int to a local int errors
correctly as does a `scope A a = new A()`.
---
import std.typecons, std.stdio;
class A { }
// Using auto ref because I don't know how to get the type of scoped
// (I guess I should file this behavior as a bug too)
auto ref fun()
{
auto a = scoped!A();
writefln("%x", &a);
return a; // Compiler should output:
// Error: escaping reference to scope local a
}
void main()
{
auto a = fun();
writefln("%x", &a);
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8421] ICE template.c:5540: Identifier* TemplateInstance::genIdent(Objects*): Assertion `global.errors' failed.
http://d.puremagic.com/issues/show_bug.cgi?id=8421 --- Comment #3 from hst...@quickfur.ath.cx 2013-10-09 09:45:18 PDT --- Should this be added to the test suite to prevent regression? -- 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 #3 from Maxim Fomin 2013-10-09 09:38:00 PDT
---
(In reply to comment #2)
> (In reply to comment #1)
> > So, what?
> >
> > Basically you are complainig about:
> >
> > import std.stdio;
> >
> > struct AGG
> > {
> > int[1] t;
> > double d;
> > }
> >
> > void main()
> > {
> > AGG tarr2 = AGG(1);
> > writeln(tarr2);
> > }
> >
> > which prints AGG([1], nan).
>
> ...Unsure what you are trying to show? the "AGG(1)".
actually the AGG([1], nan) to show struct literal behavior.
> > AGG(1) is a struct literal which is valid in D.
>
> I'm arguing that AGG should not be constructible taking a 1.
That's clear, but if you want to break the language you need to consider
writing to newsgroup. Silent language change based on some issue in bugzilla is
evil.
> > Integer literal is a valid
> > initializer for static array. Statement "AGG!S ts1 = AGG!S(1);" is rejected
> > because (unfortunately) 1 is not convertible to struct.
>
> Yes, integer is a valid initializer for a static array, and it is also a valid
> initializer for a struct that holds an int.
Right.
>
> However, 1 is not convertible to a struct,
Right. It is sad fact but in this context it is irrelevant because in the
example there is no conversion from 1 to struct, there is struct literal with
partial initializer which match initializer for first field.
> not is it convertible to a static array.
Wrong. int[1] ai = 1; ai = 1; is fine with the language so far. However in this
case we speak about struct initializer so having integer literal to be
initializer for static integer array is sufficient.
> AGG(1) should not compile, because 1 is not convertible to
> typeof(AGG.tupleof[0]);
Please refer to the spec or argue if spec is incomplete for a particular case.
Making up rules is not good. Adressing your point - this is incorrect because
typeof(AGG.tupleof[0]) has type int[1] and initializaing or assigning 1 to
int[1] is legal in D. I deliberatly unwrapped all templates to show that you
are effectivelly protesting against int[1] = 1;
> What's happening is an implicit *construction* of a static array, in a context
> where implicit construction is not allowed.
This is not the case. Here is struct literal with partial list of initializers
which match respective type initializers which is fine as far D is concern. If
you are complaining because this breaks some assumption of a brilliant phobos
ideom, this should be mentioned explicitly so some solution without damaging
language can be found (personally I object to break the language for the sake
of writing cute template in phobos).
Please don't reopen issue: CLOSED->REOPENED->CLOSED war is not good either.
--
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
monarchdo...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #2 from monarchdo...@gmail.com 2013-10-09 09:02:30 PDT ---
(In reply to comment #1)
> So, what?
>
> Basically you are complainig about:
>
> import std.stdio;
>
> struct AGG
> {
> int[1] t;
> double d;
> }
>
> void main()
> {
> AGG tarr2 = AGG(1);
> writeln(tarr2);
> }
>
> which prints AGG([1], nan).
...Unsure what you are trying to show? the "AGG(1)".
> AGG(1) is a struct literal which is valid in D.
I'm arguing that AGG should not be constructible taking a 1.
> Integer literal is a valid
> initializer for static array. Statement "AGG!S ts1 = AGG!S(1);" is rejected
> because (unfortunately) 1 is not convertible to struct.
Yes, integer is a valid initializer for a static array, and it is also a valid
initializer for a struct that holds an int.
However, 1 is not convertible to a struct, not is it convertible to a static
array. AGG(1) should not compile, because 1 is not convertible to
typeof(AGG.tupleof[0]);
What's happening is an implicit *construction* of a static array, in a context
where implicit construction is not allowed.
--
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 changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||ma...@maxim-fomin.ru
Resolution||INVALID
--- Comment #1 from Maxim Fomin 2013-10-09 08:45:45 PDT
---
So, what?
Basically you are complainig about:
import std.stdio;
struct AGG
{
int[1] t;
double d;
}
void main()
{
AGG tarr2 = AGG(1);
writeln(tarr2);
}
which prints AGG([1], nan).
AGG(1) is a struct literal which is valid in D. Integer literal is a valid
initializer for static array. Statement "AGG!S ts1 = AGG!S(1);" is rejected
because (unfortunately) 1 is not convertible to struct.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11194] std.container.Array.reserve calls opAssign on uninitialized data
http://d.puremagic.com/issues/show_bug.cgi?id=11194 --- Comment #3 from github-bugzi...@puremagic.com 2013-10-09 08:18:47 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5aac4a007adff938e5326675a039489c77c74ee6 fix issue 11194 - std.container.Array.reserve calls opAssign on uninitialized data https://github.com/D-Programming-Language/phobos/commit/4b024858a81e607214c96dc10a024d25f4af5798 Merge pull request #1620 from s-ludwig/fix_11194 fix issue 11194 - std.container.Array.reserve calls opAssign on uninitia... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11207] New: improve implicit conversions of function pointers/delegates
http://d.puremagic.com/issues/show_bug.cgi?id=11207
Summary: improve implicit conversions of function
pointers/delegates
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: eberhardhoepf...@gmx.de
--- Comment #0 from Eberhard 2013-10-09 08:03:07 PDT
---
class A {}
class B : A {}
B foo(const A) { return null; }
void main() {
A function(const A) f1 = &foo; // compiles
B function(A) f2 = &foo; // does not compile
B function(immutable A) f3 = &foo; // does not compile
B function(B) f4 = &foo; // does not compile
}
test.d(6): Error: cannot implicitly convert expression (& foo) of type B
function(const(A) _param_0) to B function(A)
test.d(7): Error: cannot implicitly convert expression (& foo) of type B
function(const(A) _param_0) to B function(immutable(A))
test.d(8): Error: cannot implicitly convert expression (& foo) of type B
function(const(A) _param_0) to B function(B)
These implicit conversions should be possible. Explicit casting is too
confusing and dangerous. If you make a mistake, you will end up with serious
runtime errors.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11206] New: static array can be implicitly built from items, when nested in aggregate
http://d.puremagic.com/issues/show_bug.cgi?id=11206
Summary: static array can be implicitly built from items, when
nested in aggregate
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2013-10-09 07:22:40 PDT ---
Just to be clear, I'm not talking about "initial construction", where, eg, this
is correct:
//
alias ARR = int[1];
struct S{int i;this(int){}}
struct AGG(T)
{
T t;
}
void main()
{
S s1 = S(1); //Explicit, OK
S s2 = 1; //Implicit, OK
ARR arr1 = [1]; //Explicit, OK
ARR arr2 = 1; //Implicit, OK
}
//
This is OK: The table makes an implicit construction, thanks to an explicit
type declaration.
However, if the table is nested inside an aggregate, then this should not
happen: Aggregate construction requires an exact type match (possibly via alias
this), *However*, individual elements *may not* be implicitly constructed from
pass in arguments:
//
void main()
{
AGG!S ts2 = AGG!S(S(2)); //Explicit. Good.
AGG!S ts1 = AGG!S(1); //NO! ILLEGAL REQUEST FOR IMPLICIT CONSTRUCTION!
AGG!ARR tarr1 = AGG!ARR([1]); //Explicit is good
AGG!ARR tarr1 = AGG!ARR(1); //This works...? [HERE]
}
//
[HERE]: This is a violation of the type system. With aggregate initialization,
each argument is supposed to match the type of the aggregated element, or be
*implicitly*castable* to said element. In the case of "element => static array
element", we have neither.
static arrays are the *only* type that allow this. I think making an exception
for static arrays is surprising and wrong. It should be rejected.
Related:
http://d.puremagic.com/issues/show_bug.cgi?id=10973
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11108] `hasElaborateAssign` should check whether the type is assignable
http://d.puremagic.com/issues/show_bug.cgi?id=11108 --- Comment #4 from github-bugzi...@puremagic.com 2013-10-09 07:05:09 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/73fa0f036a366c381beb0e784a1b28eccfe99741 Merge pull request #1623 from denis-sh/fix-Issue-11108-again-fixup-pull-1598 Fix issue 11108 again (fixup pull #1598) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11202] Copy constructor is called instead of assignment on member
http://d.puremagic.com/issues/show_bug.cgi?id=11202 --- Comment #2 from github-bugzi...@puremagic.com 2013-10-09 07:05:00 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/c930d8bd5e5246653a0300aac791b4c82b0466c5 [Workaround] Disable some tests because of Issue 11202. Issue URL: http://d.puremagic.com/issues/show_bug.cgi?id=11202 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11197] [DMD 2.064a] Struct with postblit cannot be appended to an AA of arrays
http://d.puremagic.com/issues/show_bug.cgi?id=11197 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Kenji Hara 2013-10-09 06:33:40 PDT --- Fixed: https://github.com/D-Programming-Language/dmd/commit/b5cc8954a8e3dc7f9469718a898d1aa51a64a6ba -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5469] Limitation when instantiating templates in the context of a function
http://d.puremagic.com/issues/show_bug.cgi?id=5469 --- Comment #8 from Andrej Mitrovic 2013-10-09 05:56:39 PDT --- (In reply to comment #7) > Compiles without error on 2.064 head. P.S. It looks like it was deliberately fixed, the `sx` check is in git-head. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11205] New: CodeView: Missing debug info for thunks
http://d.puremagic.com/issues/show_bug.cgi?id=11205 Summary: CodeView: Missing debug info for thunks Product: D Version: D2 Platform: All OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: aldonun...@gmail.com --- Comment #0 from Aldo Nunez 2013-10-09 04:45:19 PDT --- The compiler writes information about procedures in the CodeView debug data. But, it doesn't write anything about thunks that lead to procedures. Specifically, I find no S_THUNK32 records. For example, the compiler writes an adjustor thunk for interface methods that turn the this argument of the interface's method into the this argument of the class method that implements it. If there were information about thunks, then debuggers would know how long they are, so that the debuggers could step into the related procedures in source code mode. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11204] New: Struct is destroyed before constructed
http://d.puremagic.com/issues/show_bug.cgi?id=11204
Summary: Struct is destroyed before constructed
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: samu...@voliacable.com
--- Comment #0 from Max Samukha 2013-10-09 02:59:12
PDT ---
This illustrates what I meant in bug 10186, comment 6:
struct S {
@disable this();
bool cted;
this(int x) {
cted = true;
}
static int destroyedBeforeConstructed;
~this() {
if (!cted)
destroyedBeforeConstructed++;
}
}
class A {
S s;
this() {
s = S(1);
}
}
void main() {
auto a = new A;
assert(S.destroyedBeforeConstructed == 0);
}
Assertion fails because assignment triggers destruction of a struct that has
never been constructed.
With this one, object lifetime management remains fatally broken.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11203] New: extern (C++) classes broken
http://d.puremagic.com/issues/show_bug.cgi?id=11203
Summary: extern (C++) classes broken
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright 2013-10-09
01:55:23 PDT ---
The following code:
---
extern(C++) class C1687 {
void func() {}
}
void test1687() {
auto c = new C1687();
}
--
randomly fails at runtime because the class' .init data is all goofed up. The
size for it is correct, but the actual data is not.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11202] Copy constructor is called instead of assignment on member
http://d.puremagic.com/issues/show_bug.cgi?id=11202 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #1 from monarchdo...@gmail.com 2013-10-09 00:52:12 PDT --- Hum... the issue is that T simply doesn't care about S's opAssign: It generates its own opAssign via "postblit-copy-move" (of all of T at once I mean). This isn't strictly *wrong*, its just a pretty dirty way of doing things, and I'm pretty sure it's inefficient, and it definitly defeats the purpose of having an opAssign to begin with. It *is* the only way to provide *strong* exception guarantees though, for a compiler generated elaborate opAssign, in case one of the member's opAssign throws. *Should* we guarantee strong exception safety though? I'm unsure. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11202] New: Copy constructor is called instead of assignment on member
http://d.puremagic.com/issues/show_bug.cgi?id=11202
Summary: Copy constructor is called instead of assignment on
member
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij 2013-10-09
11:13:52 MSD ---
---
struct S
{
this(this) {}
@disable void opAssign(S);
}
struct T
{ S s; }
void main()
{
S s1, s2;
static assert(!__traits(compiles, s1 = s2));
T t1, t2;
static assert(!__traits(compiles, t1.tupleof = t2.tupleof));
static assert(!__traits(compiles, t1 = t2)); // assert fails
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
