[Issue 9012] writef/format inconsistent with format specifier
http://d.puremagic.com/issues/show_bug.cgi?id=9012 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-24 01:40:39 PST --- (In reply to comment #2) std.string.xformat is the function that's compatible with std.format. We really should deprecate std.string.format or something, and replace it with xformat. This should be sorted soon enough: https://github.com/D-Programming-Language/phobos/pull/939 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9069] New: struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069
Summary: struct literals are treated as lvalues
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2012-11-24 02:17:54
PST ---
I thought that we'd finally fixed this, but I guess that it was changed back
for some reason. With this code,
struct S
{
int i;
}
S foo(ref S s)
{
return s;
}
S bar(int i)
{
return S(i);
}
void main()
{
S s = S(2);
foo(s); //compiles as it should
foo(S(5)); //compiles when it shouldn't
foo(bar(5)); //fails to compile as it should
}
only the final call to foo gives an error, when only the first call should
compile. The second call is succeeding when it should be failing.
It makes _no_ sense to treat struct literals as lvalues. They're _not_
variables. Why on earth would struct literals be treated any differently from
string literals or numeric literals in this regard? When it's come up in the
newsgroups, I believe that the only person who has thought that this made any
sense at all is Walter. And I thought that we'd finally gotten him to change it
so that struct literals act like every other literal and are rvalues, but given
that foo(S(5)) compiles, clearly that's not the case. It should be fixed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-24
03:04:42 PST ---
I think this is the pull that should have fixed this:
http://d.puremagic.com/issues/show_bug.cgi?id=5889
Also since a recent pull this (correctly) no longer compiles:
struct S { }
void test(ref S s = S()) { }
So I think we've definitely agreed that literals are r-values. Maybe the OP
code compiles because of an oversight or wrong revert?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069 --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com 2012-11-24 03:13:58 PST --- It was discussed in the thread on const ref in the dmd-beta group during the preparations for releasing 2.060, and I think that it was fixed and then unfixed then, but I'm not sure. Regardless, the code here compiles when it shouldn't, and that needs to be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069
--- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-11-24 05:42:18 PST ---
(In reply to comment #2)
It was discussed in the thread on const ref in the dmd-beta group during the
preparations for releasing 2.060, and I think that it was fixed and then
unfixed then, but I'm not sure. Regardless, the code here compiles when it
shouldn't, and that needs to be fixed.
This behavior is introduced in 2.059beta by:
https://github.com/D-Programming-Language/dmd/pull/874
As far as I know, the main purpose was to avoid breaking existing code:
struct S {
bool opEquals(const ref S rhs) { ... }
}
void main() {
S s;
assert(s == S()); // translated to s.opEquals(S())
}
But, I believe the behavior should be *fixed*.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9071] New: sort function won't compile but Range fits describtion
http://d.puremagic.com/issues/show_bug.cgi?id=9071 Summary: sort function won't compile but Range fits describtion Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: rburn...@gmail.com --- Comment #0 from Robert Schadek rburn...@gmail.com 2012-11-24 06:32:03 PST --- The function sortImpl implies that the type returned by the slice operator of the passed range is of the same type. This must not be true. If it is not sortImpl will not instantiate recursively because of a type mismatch. This is a problem for custom container. (Currently I have this problem) To fix this. It should be checked whether or not the returned type of the opSlice funtion is of the same type as the original range. static assert(is(ReturnType!(Range.opSlice) == Range)); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9069] struct literals are treated as lvalues
http://d.puremagic.com/issues/show_bug.cgi?id=9069 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Version|unspecified |D2 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-11-24 07:16:40 PST --- https://github.com/D-Programming-Language/dmd/pull/1319 -- 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
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-24
09:59:20 PST ---
(In reply to comment #0)
template isInstanceOf(alias T, I) { ... }
That one is now in Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=9064
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9064] Add isInstanceOf to std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9064 --- Comment #2 from github-bugzi...@puremagic.com 2012-11-24 09:56:17 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e02593090a909948183921f6f00039ce3f37acff Fixes Issue 9064 - Add isInstanceOf trait. https://github.com/D-Programming-Language/phobos/commit/cc9461baa82767412ff329514a1255aa33af31aa Merge pull request #970 from AndrejMitrovic/Fix9064 Fixes Issue 9064 - Add isInstanceOf trait -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9064] Add isInstanceOf to std.traits
http://d.puremagic.com/issues/show_bug.cgi?id=9064 Alex R�nne Petersen a...@lycus.org changed: What|Removed |Added Status|NEW |RESOLVED CC||a...@lycus.org Resolution||FIXED -- 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 #2 from Manu turkey...@gmail.com 2012-11-24 10:59:39 PST ---
(In reply to comment #1)
(In reply to comment #0)
template isInstanceOf(alias T, I) { ... }
That one is now in Phobos: http://d.puremagic.com/issues/show_bug.cgi?id=9064
Sweet. Any chance of the other 2?
I'd really like to delete all my unreadable fail code asap.
--
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 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #3 from David Nadlinger c...@klickverbot.at 2012-11-24 11:01:39 PST --- For the second point, what about is(T == function)? The is() syntax is not very popular (rightfully so), but I am not sure if we have a decision to replicate even its most basic use cases in std.traits yet. -- 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 #4 from Manu turkey...@gmail.com 2012-11-24 11:48:53 PST --- (In reply to comment #3) For the second point, what about is(T == function)? The is() syntax is not very popular (rightfully so), but I am not sure if we have a decision to replicate even its most basic use cases in std.traits yet. Does that not test if T is some sort of function pointer? ...actually, that's some sort of special case overloaded meaning of the function keyword in conjunction with 'is' isn't it? I think I remember running into that like, a year ago. I recall being very confused at the time. Will that only pass in function definitions? Will exclude function pointers? The first point is by far the most important, it's the one I really have no idea how to do properly myself. I have templates that kinda work, but seem to break in some cases, and I use it constantly. -- 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 #5 from David Nadlinger c...@klickverbot.at 2012-11-24 11:51:44 PST --- (In reply to comment #4) Does that not test if T is some sort of function pointer? ...actually, that's some sort of special case overloaded meaning of the function keyword in conjunction with 'is' isn't it? I think I remember running into that like, a year ago. I recall being very confused at the time. Will that only pass in function definitions? Will exclude function pointers? Yes, this is one of the ugliest parts of the is() syntax. You are probably right, the fact alone that function has a different meaning here than in the rest of the language probably warrants inclusion of an isFunction() trait… -- 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 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #6 from Jonathan M Davis jmdavisp...@gmx.com 2012-11-24 12:13:34 PST --- is(T == function) actually tests whether T is the type of a function, not whether it's a function pointer. This stackoverflow question discusses the differences between is(T == function), isFunctionPointer!T, isDelegate!T, and isSomeFunction!T: http://stackoverflow.com/questions/11067972/functions-versus-function-pointers-whats-the-difference A related issue is issue# 4427 We may want to add more of these to std.traits, but we should probably think carefully about exactly what we should add, especially because is expressions do most (all?) of it already, and often fairly cleanly. It's just that they're complicated enough in general and not understood well enough, that many people don't have a clue what they can do. It still may be worth adding stuff like isVariable to std.traits though. -- 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 #7 from Manu turkey...@gmail.com 2012-11-24 14:35:53 PST --- (In reply to comment #6) is(T == function) actually tests whether T is the type of a function, not whether it's a function pointer. This stackoverflow question discusses the differences between is(T == function), isFunctionPointer!T, isDelegate!T, and isSomeFunction!T: http://stackoverflow.com/questions/11067972/functions-versus-function-pointers-whats-the-difference Looking at that link, what's with all the typeof(bar) stuff? Do those tempaltes not work by alias? Surely I should be able to say isSomeFunction!bar, not requiring isSomeFunction!(typeof(bar)) ? Using typeof() like that makes generic code harder, because 'bar' could be anything, and if it doesn't have a typeof, then it is a different compile error and I have to produce even more logic prior to eliminate that case. Surely that could be encapsulated? A related issue is issue# 4427 We may want to add more of these to std.traits, but we should probably think carefully about exactly what we should add, especially because is expressions do most (all?) of it already, and often fairly cleanly. It's just that they're complicated enough in general and not understood well enough, that many people don't have a clue what they can do. It still may be worth adding stuff like isVariable to std.traits though. In my experience, code to the effect of isVariable is actually rather non-trivial. It would be very useful. Ideally, written by someone who knows what they're doing ;) (I clearly don't) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4427] __traits should have isFunction, isVariable, etc
http://d.puremagic.com/issues/show_bug.cgi?id=4427 Manu turkey...@gmail.com changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #10 from Manu turkey...@gmail.com 2012-11-24 14:49:05 PST --- (In reply to comment #9) Many of these could easily be turned into templates The is ==struct and __traits are not really intended to be user-facing. They are intended to be embedded into templates which then can present a simple, straightforward user interface. Sometimes those templates do need to work hard internally to get the information, but being able to is all that's relevant. Well with this in mind, perhaps we can complete the suite of std.traits? There are a lot missing. I'd certainly like to clean up that aspect of my code before I depart, as it's the most confusing and unreadable section by far. Particularly for new-comers who haven't taken the time to wrangle those sorts of problems yet (who I will be leaving it to) :/ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8733] Normalize -of path on Windows
http://d.puremagic.com/issues/show_bug.cgi?id=8733 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-11-24 15:42:59 PST --- Forgot to mention it's a pull: https://github.com/D-Programming-Language/dmd/pull/1208 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8819] void static array should have init built-in propert
http://d.puremagic.com/issues/show_bug.cgi?id=8819 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-11-24 19:09:42 PST --- https://github.com/D-Programming-Language/dmd/pull/1324 -- 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 #9 from Jonathan M Davis jmdavisp...@gmx.com 2012-11-24 20:35:26 PST --- Looking at that link, what's with all the typeof(bar) stuff? Do those tempaltes not work by alias? Surely I should be able to say isSomeFunction!bar, not requiring isSomeFunction!(typeof(bar)) ? std.traits operates on types, so I would not expect isSomeFunction!bar to ever work. You need to pass it a type. That's how everything in that module works. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
