[Issue 12802] Allow optional 'StorageClasses' for new alias syntax
https://issues.dlang.org/show_bug.cgi?id=12802 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #4 from Kenji Hara k.hara...@gmail.com --- *** Issue 10471 has been marked as a duplicate of this issue. *** --
[Issue 10471] New alias syntax can't handle extern qualifiers
https://issues.dlang.org/show_bug.cgi?id=10471 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com --- *** This issue has been marked as a duplicate of issue 12802 *** --
[Issue 12881] New: Cannot declare a function in foreach over tuple
https://issues.dlang.org/show_bug.cgi?id=12881
Issue ID: 12881
Summary: Cannot declare a function in foreach over tuple
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: blocker
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
import std.typetuple;
void main() {
foreach(i; TypeTuple!(1, 2)) {
int foo() { return i; }
}
}
Error: declaration foo is already defined in another scope in main
--
[Issue 8693] inconsistent behavior with is a nested function and cannot be accessed from
https://issues.dlang.org/show_bug.cgi?id=8693 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Fixed in 2.061. --
[Issue 12710] Bad @nogc requirement for Windows callbacks
https://issues.dlang.org/show_bug.cgi?id=12710 --- Comment #2 from Sönke Ludwig slud...@outerproduct.org --- I've also stumbled over similar cases for EnumWindows() and signal(). The pull seems to confirm my experience with just popping attribute: at the start of a file - that almost never really works. --
[Issue 12881] Cannot declare a function in foreach over tuple
https://issues.dlang.org/show_bug.cgi?id=12881 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution|--- |DUPLICATE --- Comment #1 from yebblies yebbl...@gmail.com --- *** This issue has been marked as a duplicate of issue 4699 *** --
[Issue 4699] Functions in peer scopes cannot have the same name
https://issues.dlang.org/show_bug.cgi?id=4699 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #5 from yebblies yebbl...@gmail.com --- *** Issue 12881 has been marked as a duplicate of this issue. *** --
[Issue 4699] Functions in peer scopes cannot have the same name
https://issues.dlang.org/show_bug.cgi?id=4699 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #6 from yebblies yebbl...@gmail.com --- (In reply to bearophile_hugs from comment #4) Walter could answer if this restriction is temporary or not. This is not an intentional limitation, and will be fixed eventually. --
[Issue 1952] Support a unit test handler
https://issues.dlang.org/show_bug.cgi?id=1952 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|NEW |RESOLVED CC||c...@dawg.eu Resolution|--- |FIXED --- Comment #4 from Martin Nowak c...@dawg.eu --- There is runtime support to set the unittest handler now, so I'll close this. http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester --
[Issue 12882] New: Parser ^^ operator results in invalid result
https://issues.dlang.org/show_bug.cgi?id=12882
Issue ID: 12882
Summary: Parser ^^ operator results in invalid result
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
import std.stdio;
void main() {
real a = -2;
real b = -2.1;
(a ^^ b).writeln;
(-2 ^^ -2.1).writeln;
}
Output:
-nan
-0.233258
Should be nan in both cases.
--
[Issue 12882] Parser ^^ operator results in invalid result
https://issues.dlang.org/show_bug.cgi?id=12882
safety0ff.bugz safety0ff.b...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||safety0ff.b...@gmail.com
Resolution|--- |INVALID
--- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com ---
N.B.: ^^ has higher precedence than unary minus:
import std.stdio;
void main() {
real a = -2;
real b = -2.1;
(a ^^ b).writeln;
((-2) ^^ -2.1).writeln;
}
This gives:
-nan
nan
The sign of nan has no meaning.
--
[Issue 12882] Parser ^^ operator results in invalid result
https://issues.dlang.org/show_bug.cgi?id=12882 --- Comment #2 from Temtaime temta...@gmail.com --- This makes no sense. Why priority of ^^ is higher ? --
[Issue 12882] Parser ^^ operator results in invalid result
https://issues.dlang.org/show_bug.cgi?id=12882 --- Comment #3 from safety0ff.bugz safety0ff.b...@gmail.com --- This thread may be of interest: http://forum.dlang.org/thread/jep97e$2h9r$1...@digitalmars.com In particular, this post: http://forum.dlang.org/thread/jep97e$2h9r$1...@digitalmars.com?page=3#post-jeq0e6:24qih:241:40digitalmars.com --
[Issue 12883] New: implicit conversion of struct to mutable via alias this
https://issues.dlang.org/show_bug.cgi?id=12883
Issue ID: 12883
Summary: implicit conversion of struct to mutable via alias
this
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: ASSIGNED
Keywords: rejects-valid
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nilsboss...@googlemail.com
Reporter: nilsboss...@googlemail.com
---
static struct S
{
int x;
void* dummy;
@property S mutable() const {return S(42);}
alias mutable this;
}
void main()
{
const c = S(13);
S m1 = c;
assert(m1.x == 42);
S m2;
m2 = c;
assert(m2.x == 42);
static void f(S s) {assert(s.x == 42);}
f(c);
}
---
Pull request is on the way.
--
[Issue 12884] New: implicit conversion wrongly prefers casting immutable away over alias this when target type is base class
https://issues.dlang.org/show_bug.cgi?id=12884
Issue ID: 12884
Summary: implicit conversion wrongly prefers casting immutable
away over alias this when target type is base class
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: ASSIGNED
Keywords: wrong-code
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nilsboss...@googlemail.com
Reporter: nilsboss...@googlemail.com
---
class B {int x;}
class C : B
{
this(int x) pure {this.x = x;}
@property C mutable() const {return new C(42);}
alias mutable this;
}
void main()
{
immutable c = new C(1);
B m1 = c; /* should call alias this */
assert(m1.x == 42);
assert(m1 !is c);
}
---
Pull request is on the way.
--
[Issue 12883] implicit conversion of struct to mutable via alias this
https://issues.dlang.org/show_bug.cgi?id=12883 --- Comment #1 from Nils nilsboss...@googlemail.com --- https://github.com/D-Programming-Language/dmd/pull/3654 --
[Issue 12884] implicit conversion wrongly prefers casting immutable away over alias this when target type is base class
https://issues.dlang.org/show_bug.cgi?id=12884 --- Comment #1 from Nils nilsboss...@googlemail.com --- https://github.com/D-Programming-Language/dmd/pull/3654 --
[Issue 12883] implicit conversion of struct to mutable via alias this
https://issues.dlang.org/show_bug.cgi?id=12883 Nils nilsboss...@googlemail.com changed: What|Removed |Added Blocks||12885 --
[Issue 12885] New: const union wrongly converts implicitly to mutable
https://issues.dlang.org/show_bug.cgi?id=12885
Issue ID: 12885
Summary: const union wrongly converts implicitly to mutable
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: ASSIGNED
Keywords: accepts-invalid
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nilsboss...@googlemail.com
Reporter: nilsboss...@googlemail.com
Depends on: 12883
---
union U
{
int i;
int* p;
}
void main()
{
const U c;
U m = c;
}
---
This has been enabled by the fix to issue 11257. I think this behaviour is not
acceptable. The change has been made to allow const(Rebindable) to Rebindable
conversion. I think this should be implemented in Rebindable itself, as that's
the place where we can give the guarantee not to alter the wrapped
const/immutable data. alias this can be used for this once issue 12883 is
fixed.
--
[Issue 12886] New: std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 Issue ID: 12886 Summary: std.datetime cannot parse HTTP date Product: D Version: unspecified Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: c...@dawg.eu This functionality is needed quite often but doesn't seem to be present in phobos. The date fields in HTTP headers are encoded as date-time according to http://www.ietf.org/rfc/rfc822.txt. example: Tue, 10 Jun 2014 01:00:34 GMT specs: 5. DATE AND TIME SPECIFICATION 5.1. SYNTAX date-time = [ day , ] date time; dd mm yy ; hh:mm:ss zzz day = Mon / Tue / Wed / Thu / Fri / Sat / Sun date= 1*2DIGIT month 2DIGIT; day month year ; e.g. 20 Jun 82 month = Jan / Feb / Mar / Apr / May / Jun / Jul / Aug / Sep / Oct / Nov / Dec time= hour zone; ANSI and Military hour= 2DIGIT : 2DIGIT [: 2DIGIT] ; 00:00:00 - 23:59:59 zone= UT / GMT; Universal Time ; North American : UT / EST / EDT; Eastern: - 5/ - 4 / CST / CDT; Central: - 6/ - 5 / MST / MDT; Mountain: - 7/ - 6 / PST / PDT; Pacific: - 8/ - 7 / 1ALPHA ; Military: Z = UT; ; A:-1; (J not used) ; M:-12; N:+1; Y:+12 / ( (+ / -) 4DIGIT ); Local differential ; hours+min. (HHMM) --
[Issue 12886] std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com --- Hmmm. I don't know. Sure, the RFC 5322 date format is used in a number of internet-related specs, but the way it's parsed is rather specific to those specs. I'm not convinced that Phobos is the right place for it. I do have an implementation of this that's in a library that I've been working on (which implements RFC 5322) that I intend to post within the next couple of months (how soon will depend on how much time I have to work on it), but I am inclined to think that a 3rd party library like that is a better place for it, particularly given the insane amount of muck involved with parsing that format correctly - muck which is specific to RFC 5322 and its related specs. And I certainly wouldn't want to encourage the use of the RFC 5322 format outside of the specs that require it, since it's really a horrible format (much as it's slightly better than what was in the obsoleted RFC 822 - part of the problem being that you still have to parse the really bad stuff from RFC 822 even though it's illegal to create many such strings now with RFC 5322). --
[Issue 12886] std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 --- Comment #2 from Martin Nowak c...@dawg.eu --- I just wanted to do a very simple task, checking that the download cache in the build script doesn't use outdated files. https://github.com/D-Programming-Language/installer/blob/90a47d2a73c3150fa7f2bf82ce19e68be8b0f31e/create_dmd_release/common.d#L72 It's already a pain to get the last-modified header from std.net.curl, but parsing that date is totally out of reach. There is an simple implementation in vibe.d which oversimplifies the timezone parsing a little. https://github.com/rejectedsoftware/vibe.d/blob/8f8c9f96a8a67c3031253a1e8fc030fa59e24d00/source/vibe/inet/message.d#L149 And I certainly wouldn't want to encourage the use of the RFC 5322 format outside of the specs that require it I agree to this, how about only adding a free-standing function parseRFC822DateTime. This is somewhat similar to isEmail which doesn't really have a good place in phobos but is practically very useful. --
[Issue 12886] std.datetime cannot parse HTTP date
https://issues.dlang.org/show_bug.cgi?id=12886 --- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com --- Well, I can certainly do it, though I wouldn't make it as flexible as what I'm doing for the library that I'm working on. Supporting CFWS (comment folding whitespace) will certainly make it worse, but that would be hidden from the API. It just makes for some ugly code. Would supporting random-access ranges of char and ubyte (as well as string) be sufficient? Adding more than that pretty much means duplicating all of the code, which I don't like (much as I'm going to do it in my library for flexibility's sake), and given where these dates are _supposed_ to be used, it doesn't necessarily make sense to support wchar[] or dchar[]. Or I could just make it operate on ranges of dchar and not care much about efficiency, though I'm not a fan of that idea. What I've been working on is specifically written with the idea that you're operating on ranges of char or ubyte, because that's what IMF (rfc 5322) messages always are. --
