[Issue 9090] New: auto ref doesn't work with arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9090
Summary: auto ref doesn't work with arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jappleg...@gmail.com
--- Comment #0 from Jack Applegame 2012-11-27 23:18:41
PST ---
void test1(T)(auto ref const T[] val) {}
void main() {
string a;
test1(a);
}
Output:
Error: cast(const(char[]))a is not an lvalue
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
Rob T changed:
What|Removed |Added
CC||al...@ucora.com
--- Comment #42 from Rob T 2012-11-27 22:39:06 PST ---
(In reply to comment #26)
> (In reply to comment #24)
> > What the compiler calls stuff internally has no bearing on
> > what users of the language will call things.
>
> It's not an internal thing, that declaration is not an enum declaration,
> period. enum is used as a keyword for more than one thing, which is bad, but
> it's too late to change it now.
>
> We shouldn't name things in Phobos based on what people might think is right
> or
> looks right, but based on what the things really are.
>
> It's a shame we don't have a 'manifest' keyword of some sort, it would help
> avoid confusion. I guess 'enum' was used to cut back on having too many
> keywords in the language.
>
> Anyway it's documented behavior, see "manifest constants" here (it's at the
> bottom): http://dlang.org/enum.html
As far as I was concerned, these are anonymous enum members in the case where
there's only one member and the { } were omitted. I understood it in this way
by reading the specification here: http://dlang.org/enum.html. It actual made
some sense to me.
The use of "manifest constant" terminology elsewhere will likely cause a lot of
confusion. Why not term it as an "anonymous enum constant", or "enum manifest
constant" if that suits the usage better. Term it anything so long as "enum" is
in there so as to avoid the inevitable confusion elsewhere.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8802] Problem with enums of void*
http://d.puremagic.com/issues/show_bug.cgi?id=8802 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #4 from Rainer Schuetze 2012-11-27 22:33:14 PST --- (In reply to comment #1) > Note that there's another separate and unrelated bug here, you can't compile > this with -g. > > D:\dev\code\d_code>dmd -g test.d > test.d(4): Error: Integer constant expression expected instead of null > test.d(4): Error: Integer constant expression expected instead of null > > I'm not sure if this is filed yet. This is issue 5168. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5168] String enums don't work with -g compiler switch
http://d.puremagic.com/issues/show_bug.cgi?id=5168 Rainer Schuetze changed: What|Removed |Added Keywords||patch CC||r.sagita...@gmx.de --- Comment #7 from Rainer Schuetze 2012-11-27 22:31:46 PST --- https://github.com/D-Programming-Language/dmd/pull/1331 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9087] Value modified in foreach warning
http://d.puremagic.com/issues/show_bug.cgi?id=9087 --- Comment #3 from Kenji Hara 2012-11-27 20:23:02 PST --- (In reply to comment #2) > But I think the warning I am asking here is one of the better solutions to > avoid those bugs. Yes, in many case those *bugs* will be avoided by your enhancement. However, in few cases, if a user really wants to use the foreach key as a mutable copy of iterated element, your enhancement will reject such *correct* code. At least, that is a point described in the bug 6652 comment#0. Therefore, this is a design selection. One is avoiding "non-effect modification" bugs with blocking a few valid code. Another is to keep language expressive with a little more user's learning. I stand on latter, in basic. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9087] Value modified in foreach warning
http://d.puremagic.com/issues/show_bug.cgi?id=9087 --- Comment #2 from bearophile_h...@eml.cc 2012-11-27 19:49:45 PST --- (In reply to comment #1) > This means that the warning is not for the purpose you hope. I see, thank you for the answer Hara. But I think the warning I am asking here is one of the better solutions to avoid those bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9087] Value modified in foreach warning
http://d.puremagic.com/issues/show_bug.cgi?id=9087
--- Comment #1 from Kenji Hara 2012-11-27 19:31:53 PST ---
(In reply to comment #0)
> Currently (DMD 2.061alpha) this code generates a warning:
>
> // program#1
> void main() {
> foreach (i; 0 .. 10)
> i++;
> }
>
> test.d(4): Warning: variable modified in foreach body requires ref storage
> class
This is the *temporary* warning in progress of fixing bug 6652. Finally, the
warning will be disappeared and modifying non-ref foreach key will be
acceptable.
This means that the warning is not for the purpose you hope.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9089] New: Very restrictive Tuple constructor
http://d.puremagic.com/issues/show_bug.cgi?id=9089
Summary: Very restrictive Tuple constructor
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-27 19:26:38 PST ---
Is it possible for the Tuple constructors to have value range analysis and
accept code like this?
import std.typecons: Tuple;
alias T = Tuple!(short);
void main() {
short x = 1; // OK
T t = T(1); // error
}
Currently in DMD 2.061alpha it gives:
...\dmd2\src\phobos\std\typecons.d(406): Error: cannot implicitly convert
expression (_param_0) of type int to short
test.d(5): Error: template instance
std.typecons.Tuple!(short).Tuple.__ctor!(int) error instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9088] New: static static
http://d.puremagic.com/issues/show_bug.cgi?id=9088
Summary: static static
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-27 19:20:05 PST ---
Here I suggest an enhancement for D language (that is pure an addition, it
should cause no breaking changes).
The introduction of "static static", it roughly means "static regarding to the
template". This means that if a template contains a "static static" item, it is
shared among all instantiations of the template.
Here are some use cases:
- - - - - - - - - - - - - -
Templated classes or templated structs sometimes have member functions that are
meant to be shared among all the instantiations of the template.
struct Foo(T) {
T x;
static static int sqr(int x) { return x ^^ 2; }
}
Here static static allows to reduce template bloat, because only one sqr()
function is generated regardless the T type. Putting sqr() outside Foo is an
alternative solution, but it loses the packaging given by Foo itself (despite
the usefulness of universal call syntax).
A third solution is to put inside Foo() just a stub function that calls an
external private _sqr() function. This has both the advantage of keeping sqr()
in the the namespace, and keeps the template bloat low because only very little
sqr() are generated for each instantiation of Foo. But this requires parameter
fowarding and increases code complexity a little.
- - - - - - - - - - - - - -
There are cases where templated functions need a static variable that is shared
among all instantiations of the template:
int foo(T)() if (is(T == char) || is(T == dchar) || is(T == wchar)) {
static static dchar[] table = ['a', 'b', 'c'];
static static immutable val = someHeavyCTFE(10);
// uses table and val here
return 0;
}
In this case static static is useful to save memory, because only one table is
present for all instantiations of Foo. And only one val is computed, saving
compilation time.
An alternative design is to put both table and val outside foo(), but this adds
more global names that are better kept inside foo(), just like a static
variable in a function avoids names at module level.
This example program computes some numbers:
uint topswops(size_t nMax = 16)(in size_t n) nothrow
in {
assert(n > 0 && n < nMax);
} body {
size_t d = 0;
__gshared uint[nMax] best;
alias T = byte;
alias Deck = T[nMax];
void trySwaps(in ref Deck deck, in uint f) nothrow {
if (d > best[n])
best[n] = d;
foreach_reverse (immutable i; 0 .. n) {
if (deck[i] == -1 || deck[i] == i)
break;
if (d + best[i] <= best[n])
return;
}
Deck deck2 = deck;
d++;
uint k = 1;
foreach (immutable i; 1 .. n) {
k <<= 1;
if (deck2[i] == -1) {
if (f & k)
continue;
} else if (deck2[i] != i)
continue;
deck2[0] = cast(T)i;
foreach_reverse (immutable j; 0 .. i)
deck2[i - j] = deck[j];
trySwaps(deck2, f | k);
}
d--;
}
best[n] = 0;
Deck deck0 = -1;
deck0[0] = 0;
trySwaps(deck0, 1);
return best[n];
}
import std.stdio;
void main() {
foreach (i; 1 .. 13)
writefln("%2d: %d", i, topswops(i));
}
To speed up the computation the n argument is now a compile-time value, and
topswops() is a template:
import std.stdio, std.typetuple;
template Range(int start, int stop) {
static if (stop <= start)
alias TypeTuple!() Range;
else
alias TypeTuple!(Range!(start, stop - 1), stop - 1) Range;
}
__gshared uint[32] best;
uint topswops(size_t n)() nothrow {
static assert(n > 0 && n < best.length);
size_t d = 0;
alias T = byte;
alias Deck = T[n];
void trySwaps(in ref Deck deck, in uint f) nothrow {
if (d > best[n])
best[n] = d;
foreach_reverse (immutable i; Range!(0, n)) {
if (deck[i] == -1 || deck[i] == i)
break;
if (d + best[i] <= best[n])
return;
}
Deck deck2 = void;
foreach (immutable i; Range!(0, n)) // Copy.
deck2[i] = deck[i];
d++;
foreach (immutable i; Range!(1, n)) {
enum uint k = 1U << i;
if (deck2[i] == -1) {
if (f & k)
continue;
} else if (deck2[i] != i)
continue;
deck2[0] = cast(T)i;
foreach_reverse (immutable j; Range!(0, i))
deck2[i - j] = deck[j]; // Reverse copy.
trySwaps(deck2, f | k);
[Issue 9087] New: Value modified in foreach warning
http://d.puremagic.com/issues/show_bug.cgi?id=9087
Summary: Value modified in foreach warning
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-27 18:41:03 PST ---
Currently (DMD 2.061alpha) this code generates a warning:
// program#1
void main() {
foreach (i; 0 .. 10)
i++;
}
test.d(4): Warning: variable modified in foreach body requires ref storage
class
This is a rather common and well known source of bugs in D code (C# disallows
such mutation):
// program#2
struct S { int x; }
void main() {
auto items = [S(1), S(2), S(3)];
foreach (it; items)
it.x++;
}
(The bug is that the programmer thinks she has modified the contents of "items"
array, while the changes are just in the "it" copy, and such changes get lost
silently.)
So to both help avoid those common bugs, and improve consistency between the
two cases, I suggest to generate a warning in program#2 too, similar to:
test.d(6): Warning: mutable value modified in foreach body requires ref storage
class
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9086] New: std.typecons.appendIfNotNull() or a better idea
http://d.puremagic.com/issues/show_bug.cgi?id=9086
Summary: std.typecons.appendIfNotNull() or a better idea
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2012-11-27 18:21:31 PST ---
A problem with std.typecons.Nullable is that the D type system is not powerful
enough to see this is correct code:
import std.typecons;
void main() nothrow {
alias Nothing = Nullable!int;
Nothing[] items;
foreach (i; 0 .. 10)
items ~= (i % 2) ? Nothing(i) : Nothing();
int[] result;
foreach (x; items)
if (!x.isNull)
result ~= x.get; // Error: x.get is not nothrow
}
Another problem is that "x.get" verifies the enforcement even in the "then"
clause, this is wasted computation, because x was tested already.
One common enough use case for Nullable is to create arrays of Nullables and
then filter out the null values.
Currently code like this can't be nothrow:
items.filter!(x => !x.isNull)().map!(x => x.get)()
So I have created a little function named appendIfNotNull() that is nothrow:
import std.typecons;
void appendIfNotNull(T)(ref T[] items, Nullable!T x) pure nothrow {
try {
if (!x.isNull)
items ~= x.get;
} catch (Exception e) // enforce() exception.
assert(0);
}
// Demo code --
import std.stdio, std.algorithm;
alias Nothing = Nullable!int;
Nothing[] foo(int n) nothrow {
typeof(return) result;
foreach (i; n .. n + 6)
result ~= (i % 2) ? Nothing(i) : Nothing();
return result;
}
int[] bar() nothrow {
typeof(return) numbers;
foreach (i; 0 .. 3)
foreach (x; foo(i * 10))
numbers.appendIfNotNull(x);
return numbers;
}
void main() {
writeln(bar());
foo(1).filter!(x => !x.isNull)().map!(x => x.get)().writeln();
}
appendIfNotNull() is nothrow, but it wastes efficiency. So here is a simpler
and more efficient implementation for the std.typecons module (because _isNull
and _value fields are private):
void appendIfNotNull(T)(ref T[] items, Nullable!T x) nothrow {
if (!x._isNull)
items ~= x._value;
}
Improvements for appendIfNotNull:
- items instead of a T[] should be a range that supports appending.
- x should be allowed to be one of both types of Nullables.
appendIfNotNull() is not a very generic function, something better can be
invented, usable in more cases. More general ideas are welcome.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4596] [tdpl] Rebinding *this* in class method compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4596 --- Comment #6 from Andrej Mitrovic 2012-11-27 17:15:02 PST --- Note: http://d.puremagic.com/issues/show_bug.cgi?id=9079#c2 And Walter's comment: http://d.puremagic.com/issues/show_bug.cgi?id=780#c3 I'm not sure whether we should revert this or not. Those 4 steps Walter mentioned could have already been taken since this report was first made (even though he mentions it only this year). Unfortunately this is what happens when development procedures are written in comments instead of a more visible place.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4596] [tdpl] Rebinding *this* in class method compiles
http://d.puremagic.com/issues/show_bug.cgi?id=4596 --- Comment #7 from Andrej Mitrovic 2012-11-27 17:16:24 PST --- (In reply to comment #6) > Unfortunately this is what happens when development procedures are written in > comments instead of a more visible place.. Actually things aren't *that* grim, because this only affects Git head. So the pull for this can be reverted without much problems methinks.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8802] Problem with enums of void*
http://d.puremagic.com/issues/show_bug.cgi?id=8802 --- Comment #3 from bearophile_h...@eml.cc 2012-11-27 16:52:25 PST --- (In reply to comment #1) > I'm not sure if this is filed yet. I think that's already in Bugzilla (not filed by me). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9079] 'delete this' no longer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=9079 --- Comment #2 from siegelords_ab...@yahoo.com 2012-11-27 16:27:03 PST --- I am unhappy how this change breaks existing code without warning. The progression suggested by Walter should have been followed: http://d.puremagic.com/issues/show_bug.cgi?id=780#c3 . -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8802] Problem with enums of void*
http://d.puremagic.com/issues/show_bug.cgi?id=8802 --- Comment #2 from Andrej Mitrovic 2012-11-27 16:26:32 PST --- https://github.com/D-Programming-Language/dmd/pull/1330 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8802] Problem with enums of void*
http://d.puremagic.com/issues/show_bug.cgi?id=8802 Andrej Mitrovic changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2012-11-27 15:58:45 PST --- Note that there's another separate and unrelated bug here, you can't compile this with -g. D:\dev\code\d_code>dmd -g test.d test.d(4): Error: Integer constant expression expected instead of null test.d(4): Error: Integer constant expression expected instead of null I'm not sure if this is filed yet. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9082] Add "interleave" function
http://d.puremagic.com/issues/show_bug.cgi?id=9082 Andrej Mitrovic changed: What|Removed |Added Summary|join should accept types|Add "interleave" function |which are not ranges as the | |separator | --- Comment #1 from Andrej Mitrovic 2012-11-27 15:36:29 PST --- Changed summary. 'join' doesn't work in the way I thought it was, what I'm looking for is something different, an "interleave" type of function. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9079] 'delete this' no longer compiles
http://d.puremagic.com/issues/show_bug.cgi?id=9079 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||INVALID --- Comment #1 from Andrej Mitrovic 2012-11-27 15:32:18 PST --- See http://d.puremagic.com/issues/show_bug.cgi?id=4596 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9085] New: allow for iteration of const(V[K]) without casts
http://d.puremagic.com/issues/show_bug.cgi?id=9085 Summary: allow for iteration of const(V[K]) without casts Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dbdavid...@yahoo.com --- Comment #0 from Daniel Davidson 2012-11-27 12:09:05 PST --- As described in this thread http://forum.dlang.org/post/qqouzioewrakuhpoe...@forum.dlang.org iteration on associative arrays and certain features that use iteration, like getting the length, require a deep cast away of const. Part of the reason is the keys are copied. This is probably unnecessary and a better approach would be to have foreach(k,v;aa) assume that k is a ref const(K). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9062] AddrExp should distinguish the existence of property resolution.
http://d.puremagic.com/issues/show_bug.cgi?id=9062 David Nadlinger changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #12 from David Nadlinger 2012-11-27 10:50:27 PST --- I would not worry to much about @trusted: In my �@trusted considered harmful� thread from a while back (http://forum.dlang.org/thread/blrglebkzhrilxkbp...@forum.dlang.org), nobody could come up with a reason for keeping it part of the interface. I just didn't get around to writing a DIP resp. implementing it in DMD yet. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9084] New: Structs assignment and associative arrays
http://d.puremagic.com/issues/show_bug.cgi?id=9084
Summary: Structs assignment and associative arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ma...@maxim-fomin.ru
--- Comment #0 from Maxim Fomin 2012-11-27 10:52:35 PST
---
Assigning structs to AA arrays causes bugs due to incomplete object
construction:
import std.stdio;
struct S
{
int i = 42;
struct SS
{
int ii = 41;
this(this) { writeln("SS postblit"); }
void opAssign(SS rhs) { writeln("SS opAssign"); }
~this() { writeln(ii);}
}
SS ss;
this(this) { writeln("S postblit"); }
void opAssign(S rhs)
{
writeln("S opAssign");
}
~this()
{
writefln("i=%d, ii=%d", i, ss.ii);
}
}
S[int] map ;
// S[2] map;
// S[] map = [S(), S()];
void main()
{
map[1] = S();
}
Here program will produce not 41 and 42, but some arbitraly values because when
druntime allocates space for a new struct object in array, it does not
initialize it. Switching to fixed/dynamic array fixes program.
This causes segfault in phobos because of false assumptions about valid state
of the object:
import std.typecons;
import std.stdio;
alias RefCounted!(int) Foo;
Foo[int] map;
unittest {
map[1] = Foo();
}
void main() { }
In this code a Foo() instance is assigned into allocated but not constructed
object and because struct assignment is rewritten to opAssign call, on entering
Foo.opAssign "this" points to non-constructed object which breaks code which
assumes that object is acrually valid.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8383] 64-bit ABI: unions not the same size as in C in some situations
http://d.puremagic.com/issues/show_bug.cgi?id=8383 --- Comment #2 from David Nadlinger 2012-11-27 09:30:06 PST --- Hm, strange, I was sure I could repro this using both DMD and LDC at some point (and yes, building with -m64). In any case, thanks for taking the time to look at this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #41 from Manu 2012-11-27 09:26:36 PST ---
(In reply to comment #37)
> This is a compiler bug, not an issue of isFunction template.
> I filed new bug 9083.
I found another one, probably a compiler bug too, but I'll paste it here since
it depends on your new isVariable trait:
Boiled down as much as I could...
class Test
{
void func()
{
void templateFunc( T )( ref const T obj )
{
foreach( m; __traits( allMembers, T ) )
{
pragma(msg, m);
static if( isVariable!( __traits(getMember, T, m) ) )
{
//...
}
}
}
templateFunc( this );
}
// some class members
int x;
}
isVariable throws lots of errors when considering the class members.
Note:
__traits(allMembers, T) and __traits(getMember, T, m)
These should also work with class instances, not just types, eg:
__traits(allMembers, obj) and __traits(getMember, obj, m)
And these combinations should also work:
__traits(allMembers, T) and __traits(getMember, obj, m)
__traits(allMembers, obj) and __traits(getMember, T, m)
All these configurations throw errors, and the errors are different for each
configuration.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #40 from Manu 2012-11-27 07:59:18 PST ---
(In reply to comment #38)
> That won't work for methods, but that might not be the use case.
Yeah, if it were in std.traits, I would expect it to work on methods too.
(In reply to comment #37)
> (In reply to comment #31)
> > I am seeing a few error cases:
> >
> > enum j { k = 10 }
> >
> > pragma(msg, isFunction!(j.k));
> > pragma(msg, isManifestConstant!(j.k));
> > pragma(msg, isPropertyFunction!(j.k));
> > pragma(msg, isVariable!(j.k));
> >
> > These all throw errors.
>
> Fixed.
Huzzah!
> This is a compiler bug, not an issue of isFunction template.
> I filed new bug 9083.
Amazing!
You sir are awesome! :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #39 from Manu 2012-11-27 07:52:20 PST --- (In reply to comment #36) > Trying to take the address should do the trick. > is(typeof(&S.x)) that is. And if I have: S s; bool b = isStatic!(s.x); That solution doesn't work if 's' is an instance. I'm sick of writing really brittle code, I'm just saying that is another important std.traits. There's no trivial way to do this for an _anything_ that I can work out. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #38 from Jacob Carlborg 2012-11-27 07:35:19 PST --- (In reply to comment #36) > Trying to take the address should do the trick. > is(typeof(&S.x)) that is. That won't work for methods, but that might not be the use case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9083] mixin expression on template argument doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=9083 Kenji Hara changed: What|Removed |Added Keywords||pull, rejects-valid --- Comment #1 from Kenji Hara 2012-11-27 07:20:05 PST --- https://github.com/D-Programming-Language/dmd/pull/1328 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #37 from Kenji Hara 2012-11-27 07:19:03 PST
---
(In reply to comment #31)
> (In reply to comment #20)
> > https://gist.github.com/4152297
>
> I am seeing a few error cases:
>
> enum j { k = 10 }
>
> pragma(msg, isFunction!(j.k));
> pragma(msg, isManifestConstant!(j.k));
> pragma(msg, isPropertyFunction!(j.k));
> pragma(msg, isVariable!(j.k));
>
> These all throw errors.
Fixed.
(In reply to comment #34)
> @Kenji:
>
> I'm getting an error when using your new isFunction, here's the case:
>
> struct S
> {
> static string func(alias Class)()
> {
> foreach(m; __traits(allMembers, Class))
> {
> pragma(msg, m);
> static if( isFunction!( mixin( m ) ) )
> bool b = true;
> }
> }
>
> enum nothing = func!(typeof(this))();
> mixin(nothing);
> }
This is a compiler bug, not an issue of isFunction template.
I filed new bug 9083.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
Dmitry Olshansky changed:
What|Removed |Added
CC||dmitry.o...@gmail.com
--- Comment #36 from Dmitry Olshansky 2012-11-27
07:16:39 PST ---
(In reply to comment #35)
> I've just this afternoon encountered another one that I can't work out a nice
> way to discover:
>
> struct S
> {
> static int x;
> }
>
> bool b = isStatic!(S.x); // <- I can't think of a nice clean way to prove this
> other than trying to assign to it, which is horrible.
Trying to take the address should do the trick.
is(typeof(&S.x)) that is.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9083] New: mixin expression on template argument doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=9083
Summary: mixin expression on template argument doesn't work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara 2012-11-27 07:12:08 PST ---
Following code doesn't work.
template isFunction(X...) if (X.length == 1)
{
enum isFunction = true;
}
struct S
{
static string func(alias Class)()
{
foreach (m; __traits(allMembers, Class))
{
pragma(msg, m); // prints "func"
enum x = isFunction!(mixin(m)); //NG
//enum x = isFunction!(func); //OK
}
return "";
}
}
enum nothing = S.func!S();
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #35 from Manu 2012-11-27 06:54:34 PST ---
I've just this afternoon encountered another one that I can't work out a nice
way to discover:
struct S
{
static int x;
}
bool b = isStatic!(S.x); // <- I can't think of a nice clean way to prove this
other than trying to assign to it, which is horrible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #34 from Manu 2012-11-27 06:45:04 PST ---
@Kenji:
I'm getting an error when using your new isFunction, here's the case:
struct S
{
static string func(alias Class)()
{
foreach(m; __traits(allMembers, Class))
{
pragma(msg, m);
static if( isFunction!( mixin( m ) ) )
bool b = true;
}
}
enum nothing = func!(typeof(this))();
mixin(nothing);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #33 from Manu 2012-11-27 06:43:36 PST ---
(In reply to comment #32)
> (In reply to comment #29)
> > As a side point, what do you call X in: enum E { X = 10 } ?
> >
> > Consider:
> > enum E { X = 10 }
> > enum Y = 10;
> >
> > E.X and Y are both identical as far as I can tell.
>
> Run typeid() on them.
>
> > And every place it appears, it is clearly defined as being some subset of
> > enum.
>
> Well it wouldn't be the first time the docs lie. :)
>
> "enum Y = 10;" is a special case which the compiler checks for and then parses
> this as a manifest constant, it does not parse it as an enum. "Y" is not an
> enum value of any sort, Y is a VarDeclaration with storage class STCmanifest.
>
> Here:
> enum E { X = 10 }
>
> X is an EnumMember.
>
> Just to make this clear, these two are different:
> enum { X = 10 }
> enum Y = 10;
>
> X is an enum value, whereas Y is a manifest constant and is not associated
> with
> enums at all in any way.
That's not really how the doc describes it: "If there is only one member of an
anonymous enum, the { } can be omitted:"
Either way, it's a perfectly reasonably way to visualise it as a user. As I
said before, I couldn't care less about internal compiler terminology, it looks
like an anonymous enum value, and the doc even says it's an anonymous enum
value. It must be so.
The doc is correct as far as I'm concerned, it makes perfect sense, the
language shouldn't be defined by implementation details of DMD.
> The issue here is that the "enum" keyword can be a lie. It can mean two things
> depending on the declaration.
>
> It also seems that internally the idea of a manifest keyword was thought
> about,
> there's a bunch of commented out lines like so:
> //case TOKmanifest: stc = STCmanifest; goto Lstc;
>
> I wonder who put that in and why it wasn't used..
I'll bet it was realised during implementation that it is actually syntactic
sugar for an anonymous enum, and the enum keyword was completely appropriate :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #32 from Andrej Mitrovic 2012-11-27
06:25:56 PST ---
(In reply to comment #29)
> As a side point, what do you call X in: enum E { X = 10 } ?
>
> Consider:
> enum E { X = 10 }
> enum Y = 10;
>
> E.X and Y are both identical as far as I can tell.
Run typeid() on them.
> And every place it appears, it is clearly defined as being some subset of
> enum.
Well it wouldn't be the first time the docs lie. :)
"enum Y = 10;" is a special case which the compiler checks for and then parses
this as a manifest constant, it does not parse it as an enum. "Y" is not an
enum value of any sort, Y is a VarDeclaration with storage class STCmanifest.
Here:
enum E { X = 10 }
X is an EnumMember.
Just to make this clear, these two are different:
enum { X = 10 }
enum Y = 10;
X is an enum value, whereas Y is a manifest constant and is not associated with
enums at all in any way.
The issue here is that the "enum" keyword can be a lie. It can mean two things
depending on the declaration.
It also seems that internally the idea of a manifest keyword was thought about,
there's a bunch of commented out lines like so:
//case TOKmanifest: stc = STCmanifest; goto Lstc;
I wonder who put that in and why it wasn't used..
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #31 from Manu 2012-11-27 05:37:31 PST ---
(In reply to comment #20)
> https://gist.github.com/4152297
I am seeing a few error cases:
enum j { k = 10 }
pragma(msg, isFunction!(j.k));
pragma(msg, isManifestConstant!(j.k));
pragma(msg, isPropertyFunction!(j.k));
pragma(msg, isVariable!(j.k));
These all throw errors.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #29 from Manu 2012-11-27 04:51:33 PST ---
(In reply to comment #26)
> (In reply to comment #24)
> > What the compiler calls stuff internally has no bearing on
> > what users of the language will call things.
>
> It's not an internal thing, that declaration is not an enum declaration,
> period. enum is used as a keyword for more than one thing, which is bad, but
> it's too late to change it now.
>
> We shouldn't name things in Phobos based on what people might think is right
> or
> looks right, but based on what the things really are.
I couldn't disagree more.
Firstly, what it is clearly documented as, is being some subset of enum. That's
what it 'really is'.
More importantly, if I look at the top of std.traits for something I presume to
be called isEnum, and I see isEnumValue, I'll realise that's actually what I'm
looking for immediately, use it, and save myself time.
If I see something called isEnum, and it doesn't seem to work because it only
reports true for enum TYPES (not values), then I'll declare it broken and
report a bug.
If I scan through everything in std.traits, and find nothing that looks like
what I want, I'll get frustrated the thing I need is missing.
If I see isManifestConstant, there is _NO WAY_ I would have even read what that
is, it's clearly not what I'm looking for, I'm trying to identify if my thing
is an enum...
> It's a shame we don't have a 'manifest' keyword of some sort, it would help
> avoid confusion. I guess 'enum' was used to cut back on having too many
> keywords in the language.
I honestly don't even know what manifest means. The terminology used in the
syntax and the documentation is correct; it's a kind of enum.
> Anyway it's documented behavior, see "manifest constants" here (it's at the
> bottom): http://dlang.org/enum.html
And every place it appears, it is clearly defined as being some subset of enum.
Again, if I go looking for isEnum, and find a suite of more specific enum
related traits (isEnumType, isEnumValue), I can easily conclude which is the
one I'm looking for. If the name is completely unrelated and uses terminology
most programmers have never heard before, they'll never spot it.
As a side point, what do you call X in: enum E { X = 10 } ?
Consider:
enum E { X = 10 }
enum Y = 10;
E.X and Y are both identical as far as I can tell. I would presume:
isEnumType!E == true, and isEnumValue!(E.X) == isEnumValue!Y == true.
You can tweak the names, but I think traits to that effect are a) useful, b)
what (I presume) most typical users will expect.
E.X and Y are identical. I think this specialised term 'manifest constant' that
only applies to Y can only result in confusion.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #30 from Manu 2012-11-27 04:53:31 PST --- (In reply to comment #28) > (In reply to comment #26) > > > It's a shame we don't have a 'manifest' keyword of some sort, it would help > > avoid confusion. I guess 'enum' was used to cut back on having too many > > keywords in the language. > > Isn't the whole problem that the compiler and/or linker isn't capable of > stripping out symbols that are only used at compile time. It's also one of the things that D got absolutely right! I never questioned this design for a moment, it makes perfect sense to me, but as of yesterday my concept of what an enum is has been thrown up in the air for absolutely no good reason other than terminology used by the D developers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #28 from Jacob Carlborg 2012-11-27 04:41:46 PST --- (In reply to comment #26) > It's a shame we don't have a 'manifest' keyword of some sort, it would help > avoid confusion. I guess 'enum' was used to cut back on having too many > keywords in the language. Isn't the whole problem that the compiler and/or linker isn't capable of stripping out symbols that are only used at compile time. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #27 from Andrej Mitrovic 2012-11-27 04:15:48 PST --- (In reply to comment #26) > Anyway it's documented behavior, see "manifest constants" here (it's at the > bottom): http://dlang.org/enum.html Actually it's poorly documented, it speaks about "anon" enums but it shouldn't really mention them at all imo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #26 from Andrej Mitrovic 2012-11-27 04:14:28 PST --- (In reply to comment #24) > What the compiler calls stuff internally has no bearing on > what users of the language will call things. It's not an internal thing, that declaration is not an enum declaration, period. enum is used as a keyword for more than one thing, which is bad, but it's too late to change it now. We shouldn't name things in Phobos based on what people might think is right or looks right, but based on what the things really are. It's a shame we don't have a 'manifest' keyword of some sort, it would help avoid confusion. I guess 'enum' was used to cut back on having too many keywords in the language. Anyway it's documented behavior, see "manifest constants" here (it's at the bottom): http://dlang.org/enum.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9082] New: join should accept types which are not ranges as the separator
http://d.puremagic.com/issues/show_bug.cgi?id=9082 Summary: join should accept types which are not ranges as the separator Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2012-11-27 04:05:05 PST --- int[] arr = [1, 2, 3].join(0); // fail Expected: [1, 0, 2, 0, 3] This should work with any separator type if it's the element type of the range. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065 --- Comment #25 from Manu 2012-11-27 04:06:02 PST --- (In reply to comment #24) > This highlights another conflict in terminology, currently a property is NOT > recognised as a function (at least in my crappy tests). I really think > isFunction!someProperty should be true. It's a function, exactly like any > other, I can take pointers/delegates of it, it just has a particular usage > semantic. Effectively a subset, not a different concept. > > So I suggest isFunction! should give true for a property function definition. Sorry! I just saw your unit test asserts isFunction! is true for property functions. I didn't see that behaviour with is(X==function) in my tests. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9065] Please consider adding these std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9065
--- Comment #24 from Manu 2012-11-27 03:57:58 PST ---
(In reply to comment #22)
> > I'm not sold on the term isManifestConstant, I'm sure no non-compiler
> > developer would have ever heard that term before. I've never seen it in any
> > docs before, and they're declared with 'enum', that's what most people will
> > call it.
>
> I don't know if isManifestConstant is the best name, but it's the official
> term, and I'm sure that a large portion of the regular newsgroup goers know
> what it is, not just the compiler devs. I don't know how many outside that
> group would know it however. Still, given that it's the official name, and
> that
> we don't really _have_ another name, I think that I'd still be in favor of
> isManifestConstant. And if we have isManifestConstant and isEnumType and no
> isEnum, then we avoid all of the confusion surrounding what exactly an enum
> is.
> And it's not like it will be hard for the docs to explain the terms.
There is another name, it's called an 'enum', as clearly stated by the syntax:
enum x = 10;
Using any term other than that seems crazy by my measure. The user base aren't
compiler developers. I don't even know what manifest means.
I don't think the distinction isEnumType, isEnumValue is at all confusing, in
fact, the function names alone document the important detail that there IS a
distinction, and what it is.
(In reply to comment #23)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > I challenged implementing proposed template isVariable. Is this what you
> > > want?
> > >
> > > https://gist.github.com/4152297
> >
> > It looks good, although I can't test it now.
> > Does isVariable deal with properties (which I would say are NOT variables).
> > And
> > how about an isProperty? That's really hard to detect...
>
> Added isPropertyFunction (isProperty is a bit ambiguous name to me).
> I think it's a trait derived from isFunction.
This highlights another conflict in terminology, currently a property is NOT
recognised as a function (at least in my crappy tests). I really think
isFunction!someProperty should be true. It's a function, exactly like any
other, I can take pointers/delegates of it, it just has a particular usage
semantic. Effectively a subset, not a different concept.
So I suggest isFunction! should give true for a property function definition.
> > I'm not sold on the term isManifestConstant, I'm sure no non-compiler
> > developer
> > would have ever heard that term before. I've never seen it in any docs
> > before,
> > and they're declared with 'enum', that's what most people will call it.
>
> http://dlang.org/features2.html
> > Extended enums to allow declaration of manifest constants.
This clearly implies that 'manifest constant' is in fact some kind of enum.
> http://dlang.org/enum.html
> > Manifest Constants
> > If there is only one member of an anonymous enum, the { } can be omitted:
> > [snip]
> > Such declarations are not lvalues, meaning their address cannot be taken.
Again, referring to 'anonymous enum', it's not distancing its self from the
enum terminology.
...
I just asked 2 other programmers in the room what enum x = 10; is, they said
it's an enum, not a manifest constant ;)
None of them could tell me what a manifest constant it, or that they'd ever
heard of such a thing before.
But I don't actually care at the end of the day, I'm just trying to give a
voice of reason. What the compiler calls stuff internally has no bearing on
what users of the language will call things. The user facing library should
endeavour to match the terminology used by the users IMO.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9034] errors of conversions in format.d
http://d.puremagic.com/issues/show_bug.cgi?id=9034
--- Comment #2 from js.m...@gmail.com 2012-11-27 03:25:25 PST ---
(In reply to comment #1)
> A minimal test case to go with those errors would be helpful.
Use a rather bare bones d example and trying to compile for x64 in windows by
adding the -m64 switch gave the same results. Seems like it is a conversion
issue due the fact that length depends on the architecture.
Changing the line in format.d "uint sl;" to "size_t sl;" solves the errors but
then gives
-- Build started: Project: CTest1, Configuration: Release Win64 --
Building Release\CTest1.exe...
Internal error: ..\ztc\cgobj.c 1479
Building Release\CTest1.exe failed!
Using casts instead of size_t also gives the same error.
The code is
" else// 16 bit segment
{
#if MARS
assert(0); // line 1479
#else
if (size & ~0xL)
{ if (size == 0x1)// if exactly 64Kb
sd[0] |= 2; // set "B" bit
else
synerr(EM_seg_gt_64k,size); // segment exceeds 64Kb
}
//printf("attr = %x\n", attr);
#endif
}"
Which seems to be how the compiler is dealing with object files and the 64-bit
object segments are treated as 16-bit. (A guess as I'm new to D but jives with
what was said about the 64-bit issues DMD had)
In any case the uint seems to be a bug as much of the code surrounding it uses
size_t's.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8383] 64-bit ABI: unions not the same size as in C in some situations
http://d.puremagic.com/issues/show_bug.cgi?id=8383 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Don 2012-11-27 02:54:38 PST --- With github head for D2, this gives sizeof a: 32 when compiled with -m64 on Linuxx86_64. It only gives sizeof: a == 20 when compiled with -m32. This is true even on 1.073, released five months before this bug report was made. So I cannot reproduce this at all. Did the original poster fail to use the -m64 flag? It could of course have been an even older bug which was fixed before the start of 2012. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
