[Issue 10143] Make -property do nothing in preparation for removal
http://d.puremagic.com/issues/show_bug.cgi?id=10143 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2013-05-31 08:41:52 PDT --- The consensus was definitely in favor of _not_ having strict property enforcement, and I believe that both Walter and Andrei agreed with that, and without strict property enforcement, -property is pointless and incorrect. So, I would fully expect Walter or Andrei to pre-approve this if they saw it, but AFAIK, they haven't read this enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6461] multiple definitions with typeid and multiobj
http://d.puremagic.com/issues/show_bug.cgi?id=6461 --- Comment #12 from Martin Nowak c...@dawg.eu 2013-05-31 09:19:19 PDT --- (In reply to comment #11) (In reply to comment #10) IIRC TypeInfo instances were the only symbols where s-getModule() returns NULL. I had the impression that the init-data has the same problem, but I could also have been confused by other issues (the multiobj library creation doesn't work at all for omf atm). But a TypeInfo instance should belong to the module of the described Type. I hope that we can remove the hack if we fix that behavior and assert s-getModule. The problem also exists for derived types like const(Struct) or Struct* (maybe also for basic types?). You cannot generate all possible types into the module itself (and you might not have it compiled anyway if the declaration is only in a di file). E.g. for const(Struct) you'll have to at least generate the TypeInfo_Const that refers to TypeInfo_Struct somewhere into the current compiler output. True, but wouldn't it still make sense to emit these into a doppelg�nger module of the original module? One problem is, that this required linking against the original module, because it references assert etc. As this only seems to happen with data we don't actually need the module functions, so we could omit them. Also emitting them to a doppelg�nger of a special anonymous module would make more sense than to reuse the last filename. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7533] Error with no line number with pure static ctor
http://d.puremagic.com/issues/show_bug.cgi?id=7533 --- Comment #2 from github-bugzi...@puremagic.com 2013-05-31 09:16:39 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ef183a175926568f6757a8037cdaf1aa26489375 fix issue 7533 - Error with no line number with pure static ctor https://github.com/D-Programming-Language/dmd/commit/dc11daccfdfa5d7393017149b16877d9057ce36d Merge pull request #2108 from hpohl/7533 fix issue 7533 - Error with no line number with pure static ctor -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10218] std.typecons.opAssign is not CTFEable
http://d.puremagic.com/issues/show_bug.cgi?id=10218 --- Comment #2 from Hisayuki Mima youx...@gmail.com 2013-06-01 01:29:56 JST --- https://github.com/D-Programming-Language/phobos/pull/1325 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8008] static array literal syntax request: auto x=[1,2,3]S;
http://d.puremagic.com/issues/show_bug.cgi?id=8008 Shriramana Sharma samj...@gmail.com changed: What|Removed |Added CC||samj...@gmail.com --- Comment #3 from Shriramana Sharma samj...@gmail.com 2013-05-31 10:18:19 PDT --- (In reply to comment #2) Thanks for the reply, I wish this could receive more attention... If you're worried about esthetics, how about using a distinct symbol instead of a letter to make it pop out: For example: auto x=[1,2,3]@; fun([1,2,3]@); I also don't like [,,,]S syntax. But i.o. @ I think we can re-use the $ which is suggested for specifying in the type as in bug 481. But even then, such a special syntax would only be needed if it is necessary for specifying in a literal that a fixed-size array is intended. In assignment or other expressions it would not be required but only in direct function arguments. And even then, why wouldn't a function that expects a fixedsize array not accept a dynamic one of appropriate size? If it doesn't accept, then probably that is what should be fixed and no new syntax for such fixed-size array literals is needed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8008] static array literal syntax request: auto x=[1,2,3]S;
http://d.puremagic.com/issues/show_bug.cgi?id=8008
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-05-31
10:27:09 PDT ---
(In reply to comment #0)
* no easy way to pass a static array literal to a function accepting a static
array; for example it requires:
int[3] x=[1,2,3];
fun(x);
That can't be true. This works fine:
-
void fun(int[3] arr) { }
void main()
{
fun([1, 2, 3]);
}
-
I've tried it with 2.050, and it worked there.
Additionally since 2.063 you can also do:
-
void fun(int[3] arr) { }
void main()
{
auto x = [1, 2, 3];
fun(x[0 .. 3]);
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4565] In array literals single values can replace arrays of length 1
http://d.puremagic.com/issues/show_bug.cgi?id=4565 Shriramana Sharma samj...@gmail.com changed: What|Removed |Added CC||samj...@gmail.com --- Comment #7 from Shriramana Sharma samj...@gmail.com 2013-05-31 10:33:43 PDT --- (In reply to comment #4) I think this is not a bad program. int[1][3] a1 = [1, 2, 3]; is same as: int[1][3] a1 = void; a1[0][] = 1; // fill all elements by 1 a1[1][] = 2; // fill all elements by 2 a1[2][] = 3; // fill all elements by 3 Then a1 is initialized by [[1], [2], [3]]. And it is consistent with: int[3] sa = 1; // sa is initialized to [1, 1, 1] FWIW I agree with bearophile here. In the case of having a single value on the RHS it is easy (?) to construe how int[3] a = 1 (or even maybe int[3][3] a = 1) would initialize all the elements, but when you specify an array literal on the RHS, I think it should have the same shape as the array specified in the type on the LHS to avoid hard-to-find bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 481] Letting compiler determine length for fixed-length arrays
http://d.puremagic.com/issues/show_bug.cgi?id=481 Shriramana Sharma samj...@gmail.com changed: What|Removed |Added CC||samj...@gmail.com --- Comment #16 from Shriramana Sharma samj...@gmail.com 2013-05-31 10:37:21 PDT --- FWIW I vote for using int[$] a = [ 1,2,3,4 ] syntax for this. auto[$] would of course also be valid to allow compile-time type inference. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10184] Port Tango's concurrent garbage collector (CDGC) to D2's druntime
http://d.puremagic.com/issues/show_bug.cgi?id=10184 --- Comment #3 from Leandro Lucarella leandro.lucare...@sociomantic.com 2013-05-31 10:35:48 PDT --- https://github.com/D-Programming-Language/druntime/pull/500 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7533] Error with no line number with pure static ctor
http://d.puremagic.com/issues/show_bug.cgi?id=7533 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Status|NEW |RESOLVED CC||henn...@still-hidden.de Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3849] Compiler should catch incomplete initialisation of an array
http://d.puremagic.com/issues/show_bug.cgi?id=3849 Shriramana Sharma samj...@gmail.com changed: What|Removed |Added CC||samj...@gmail.com --- Comment #21 from Shriramana Sharma samj...@gmail.com 2013-05-31 10:48:29 PDT --- (In reply to comment #16) (In reply to comment #14) with the comma, the remainder of elements would be initialised to the type's .init. A ... following a value without a comma would, OTOH, initialise all remaining elements to the specified value. An engineer usually prefers KISS designs, this also means that language features serve for only one purpose. The sub-feature you propose is cute, but I think seen from the eyes of an engineer it risks reducing the value of the whole ellipsis feature :-| I support the ... syntax to indicate an incomplete array specification for a fixed-size array. Of course, the T[$]= syntax prescribed by bug 481 should not be used with this syntax since they conflict. 1) IMHO absence of a comma between two items inside an array literal should be treated as an error. 2) However, at the end of the specified elements of an array literal, a comma may or may not be present before the ... and it should NOT make any difference -- all the remaining objects should be initialized to T.init. Making a semantic difference on the small distinction between 3,... and 3... would be a bad decision IMHO. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10219] New: Implicit conversion between delegates returning a class and an interface
http://d.puremagic.com/issues/show_bug.cgi?id=10219
Summary: Implicit conversion between delegates returning a
class and an interface
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: accepts-invalid, wrong-code
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-05-31
21:55:56 MSD ---
---
interface I { }
class C: I { }
void f(I delegate(C) del)
{
C c = new C;
void* cPtr = cast(void*) c;
void* iPtr = cast(void*) cast(I) c;
void* delPtr = cast(void*) del(c);
assert(cPtr != iPtr);
assert(cPtr != delPtr); // fails
assert(iPtr == delPtr); // fails
}
// Incorrect implicit conversion example
static assert(!__traits(compiles, f(delegate C(C c) { return c; }))); // fails
void main()
{
// As a result wrong code is generated for lambdas
f(c = c); // creates delegate C(C), not I(C)
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10220] New: `array` doesn't work with disabled default construction
http://d.puremagic.com/issues/show_bug.cgi?id=10220 Summary: `array` doesn't work with disabled default construction Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: rejects-valid Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: verylonglogin@gmail.com --- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2013-05-31 22:06:03 MSD --- Bacause of phobos pull 1305 [1] there is now `new E[]` code in `arrayAllocImpl` which fails to compile if `E` disabled default construction. [1] https://github.com/D-Programming-Language/phobos/pull/1305 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10210] calling through PLT trashes EAX
http://d.puremagic.com/issues/show_bug.cgi?id=10210 --- Comment #1 from Martin Nowak c...@dawg.eu 2013-05-31 11:52:36 PDT --- Until now I don't know any solution other than to not use EAX for parameter passing. Maybe ECX or EDX would work as alternative. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1654] Array concatenation should result in mutable or invariant depending on usage
http://d.puremagic.com/issues/show_bug.cgi?id=1654
--- Comment #28 from bearophile_h...@eml.cc 2013-05-31 11:57:29 PDT ---
An example of code we like to compile:
void main() {
immutable data1 = [10, 20];
immutable data2 = data1 ~ [30];
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3096] EnumBaseType
http://d.puremagic.com/issues/show_bug.cgi?id=3096 Henning Pohl henn...@still-hidden.de changed: What|Removed |Added Keywords||pull CC||henn...@still-hidden.de --- Comment #1 from Henning Pohl henn...@still-hidden.de 2013-05-31 15:10:07 PDT --- https://github.com/D-Programming-Language/dmd/pull/2112 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10221] New: foreach(char c; 0..256) doesn't work even though the upper bound is 255
http://d.puremagic.com/issues/show_bug.cgi?id=10221
Summary: foreach(char c; 0..256) doesn't work even though the
upper bound is 255
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-05-31 16:32:55 PDT ---
foreach(char c; 0..256) doesn't work even though the upper bound is 255:
Error: cannot implicitly convert expression (256) of type int to char
Maybe instead disallow: foreach(char c; 0..257) ?
Is that a bug, or how would we achieve iterating over all chars without
resorting to :
foreach(c_; 0..256){
char c=c_.to!char;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10117] Support C++ class-scope static variables
http://d.puremagic.com/issues/show_bug.cgi?id=10117 --- Comment #1 from github-bugzi...@puremagic.com 2013-05-31 17:55:17 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/83096425d641ab2bdbbf153b3a4998b3fb430dd2 fix Issue 10117 - Support C++ class-scope static variables https://github.com/D-Programming-Language/dmd/commit/be3653bc3e80938a177e7bffda69ff00391bc558 Merge pull request #2053 from IgorStepanov/cppstaticvar fix Issue 10117 - Support C++ class-scope static variables -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10117] Support C++ class-scope static variables
http://d.puremagic.com/issues/show_bug.cgi?id=10117 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 10221] foreach(char c; 0..256) doesn't work even though the upper bound is 255
http://d.puremagic.com/issues/show_bug.cgi?id=10221 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-05-31 18:39:10 PDT --- This is similar to what I've ran into 2 years ago: http://www.digitalmars.com/d/archives/digitalmars/D/learn/Foreach_with_byte_problems_24997.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9976] Needlessly large instantiation depth in std.typetuple algorithms
http://d.puremagic.com/issues/show_bug.cgi?id=9976 --- Comment #10 from github-bugzi...@puremagic.com 2013-05-31 18:55:57 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d3df489171890ccdd73708a3edfa047efa01c4d2 fix Issue 9976 - Needlessly large instantiation depth in std.typetuple algorithms https://github.com/D-Programming-Language/phobos/commit/69f5377acd873301fd9f7cd742e9229050bb4342 Merge pull request #1274 from 9rnsr/fix9976 Apply ddoc-ed unittest feature in std.typetuple, and fix issue 9976 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9976] Needlessly large instantiation depth in std.typetuple algorithms
http://d.puremagic.com/issues/show_bug.cgi?id=9976 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #11 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-05-31 18:57:43 PDT --- (In reply to comment #9) I'm not sure, but, is this right? template MostDerived(T, TList...) Is this the last one left? Someone should make a pull for it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10017] Can not assign to a Variant another Variant holding a bigger structure
http://d.puremagic.com/issues/show_bug.cgi?id=10017 --- Comment #11 from David Eagen da...@eagen.com 2013-05-31 19:00:23 PDT --- (In reply to comment #10) (In reply to comment #8) (In reply to comment #7) You are right, sorry for the confusion. It should have been merged into 2.063 though because bug 9122 was marked as regression. Ok. I pushed the fix to 2.063 branch. Looks like the fix isn't in the 2.063 release binaries. At least not the Linux 64-bit ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10222] New: Instructions for building dmd and Phobos on OSX are wrong
http://d.puremagic.com/issues/show_bug.cgi?id=10222 Summary: Instructions for building dmd and Phobos on OSX are wrong Product: D Version: D2 Platform: All OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: websites AssignedTo: nob...@puremagic.com ReportedBy: redballoo...@gmail.com --- Comment #0 from Paul O'Neil redballoo...@gmail.com 2013-05-31 20:35:00 PDT --- The instructions for building dmd and Phobos on OSX (http://dlang.org/dmd-osx.html) say to use the makefile osx.mak. This file doesn't exist anywhere. Using posix.mak instead seems to work for Phobos. In the dmd instructions, there are more problems. The instructions currently are: cd ~/dmd2/src/dmd make -f osx.mak In the dmd source tree, src/dmd is an executable, not a directory. Running make -f posix.mak doesn't do anything. There is an Xcode project in the top level directory that does the make -f posix.mak and doesn't produce a binary. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10208] Module-level const/immutable variables with initialization value don't support UDAs
http://d.puremagic.com/issues/show_bug.cgi?id=10208 --- Comment #2 from github-bugzi...@puremagic.com 2013-05-31 21:02:56 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ff7270da2b14503c723124f840a69cb8adebe3df fix Issue 10208 - Module-level const/immutable variables with initialization value don't support UDAs https://github.com/D-Programming-Language/dmd/commit/4aac3b50b4516974d4b9e42b268c0ef7f6667a7c Merge pull request #2100 from 9rnsr/fix10208 Issue 10208 - Module-level const/immutable variables with initialization value don't support UDAs -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10208] Module-level const/immutable variables with initialization value don't support UDAs
http://d.puremagic.com/issues/show_bug.cgi?id=10208 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: ---
