[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #16 from hst...@quickfur.ath.cx --- And this time, I remembered to set you as author, unlike the previous patches I turned into PRs. I know you said it doesn't matter, but still. :-) --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #23 from hst...@quickfur.ath.cx --- Built-in AA's was one of the things that initially drew me to D. Though, admittedly, I would've been OK with a library type that sported convenient syntax. But as they say, hindsight is always 20/20. In the early days, D simply wasn't powerful enough for a library type to be able to emulate what built-in AA's do. Today, of course, the tables have turned, and a library type may in fact be superior to the built-in type if given proper compiler support. (One thing that comes to mind is using templates and compile-time introspection to optimize AA operations, that today have to rely on passing typeinfo's around and thereby being handicapped when it comes to dealing with things like @disabled ctors, non-trivial opAssign's, and so on. A library type would have no such problem.) --
[Issue 13533] DateTime.fromISOExtString should also accept space separator (instead of 'T')
https://issues.dlang.org/show_bug.cgi?id=13533 Martin Nowak changed: What|Removed |Added Summary|DateTime.fromSimpleString |DateTime.fromISOExtString |should accept numerical |should also accept space |months |separator (instead of 'T') --
[Issue 13489] Boolean semantics of floating point types should use "<> 0"
https://issues.dlang.org/show_bug.cgi?id=13489 yebblies changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #7 from yebblies --- (In reply to Walter Bright from comment #2) > Having cast(bool)d rewritten to be d<>0 is also problematic as Don Clugston > is a vocal advocate of having the <> operator removed from D. This is not problematic, the compiler using it internally does not mean it has to be exposed to the user. --
[Issue 13533] DateTime.fromSimpleString should accept numerical months
https://issues.dlang.org/show_bug.cgi?id=13533 --- Comment #1 from Martin Nowak --- Replacing the T with a space seems to be a small deviation from ISO8601 used by some people for better readability, so the correct place for this would be fromISOExtString. --
[Issue 12597] Payload getter for std.typecons.Typedef
https://issues.dlang.org/show_bug.cgi?id=12597
--- Comment #13 from monkeywork...@hotmail.com ---
(In reply to bearophile_hugs from comment #12)
> (In reply to monkeyworks12 from comment #11)
> > I think this enhancement request should be closed now that
> > https://github.com/D-Programming-Language/phobos/pull/2116 has been merged.
> > With that PR, your first example now becomes:
> >
> > void main() {
> > import std.typecons: Typedef;
> > import std.math: sin;
> > alias Angle = Typedef!double;
> > Angle x = 0.5;
> > auto y1 = sin(x); // Error.
> > auto y2 = sin(cast(TypedefType!Angle)x); // OK.
> > }
> >
> > A bit verbose, but it accomplishes what you want and is more DRY and safer
> > than cast(double)x.
>
> This ER asks for a function like "typedefVal" that's usable like:
>
> auto y2 = x.typedefVal.sin; // OK.
>
> Casts are unsafe, their usage should be minimized in D code. So this ER is
> still valid.
But casting to TypedefType!(typeof(x)) is always safe, so if you want such a
function, it's trivial to add one yourself. The main problem (getting the
underlying type of a Typedef) is solved.
auto typedefVal(T)(T val)
{
return cast(TypedefType!T)val;
}
--
[Issue 13522] Let's use '_' underscore as official ignore value
https://issues.dlang.org/show_bug.cgi?id=13522 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #4 from Ketmar Dark --- it shouldn't, but we can use two underscores for that. ids started with two underscores are reserved anyway. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #15 from Ketmar Dark --- tnx for turning this into PR. --
[Issue 13533] New: DateTime.fromSimpleString should accept numerical months
https://issues.dlang.org/show_bug.cgi?id=13533 Issue ID: 13533 Summary: DateTime.fromSimpleString should accept numerical months Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: c...@dawg.eu I often stumble over datetime strings in this format. 2014-09-26 10:20:30 +0200 Most notably MySQL and Ruby's Time class use it. I haven't yet found a good way to parse this format into a DateTime. The function fromSimpleString will only accept date formats with abbreviated months as in `2014-Sep-26 10:20:30 +0200`, fromISOExtString OTOH requires a 'T' between the date and uses a different format for the timezone. So it would be nice if Date.fromSimpleString accepted "2014-09-26". Workarounds aren't really possible, e.g. because SimpleTimeZone.fromISOString isn't accessible. --
[Issue 13522] Let's use '_' underscore as official ignore value
https://issues.dlang.org/show_bug.cgi?id=13522 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #3 from hst...@quickfur.ath.cx --- Would this cause interop problems with C programs that use GNU gettext, which conventionally defines '_' to be shorthand for 'gettext'? (Not that I care about such an ugly C hack, but you never know, somebody might care.) --
[Issue 13532] std.regex performance (enums; regex vs ctRegex)
https://issues.dlang.org/show_bug.cgi?id=13532 Vladimir Panteleev changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #2 from Vladimir Panteleev --- Well, it's slower for this particular case, not necessarily in general. CCing Dmitry. --
[Issue 13528] Internal Compiler Error: CTFE DotType:
https://issues.dlang.org/show_bug.cgi?id=13528 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||ice CC||hst...@quickfur.ath.cx Severity|normal |critical --
[Issue 13532] std.regex performance (enums; regex vs ctRegex)
https://issues.dlang.org/show_bug.cgi?id=13532 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- ctRegex is slower than regular regex?! Whoa. That just sounds completely wrong. What's the cause of this slowdown? I thought the whole point of ctRegex is to outperform runtime regex by making use of compile-time optimization. Whatever happened to that?? If this is the case, we might as well throw ctRegex away. --
[Issue 13529] std.string.lastIndexOf matches wrong element
https://issues.dlang.org/show_bug.cgi?id=13529 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution|--- |FIXED --- Comment #3 from hst...@quickfur.ath.cx --- Verified fixed in git HEAD, Linux/64. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #22 from yebblies --- (In reply to Ketmar Dark from comment #21) > (In reply to yebblies from comment #20) > > Anyone looking for high performance in the built-in AAs is on the wrong > > track. > but why? Because AAs can be optimized for different usage patterns, but builtin AAs cannot. I'm not saying we shouldn't care at all about their performance, just that usability is more important concern as their performance is less likely to be critical. > it's wrong to assume that AA has any defined order of items for > iteration. this is *really* wrong. Yes, it's wrong, but it's convenient. Deterministic behavior is always nice to have. > but there is nothing wrong with fast and > memory-effective built-in AAs. why include language feature that is known to > be slow when it can be reasonably fast? It's a trade-off. > built-in AAs are very handy. and if they known to be slow, people will start > to roll their own AA implementations virtually each time they want to use > AA. and then we can just kill built-in AAs altogether. People rolling their own specialized AAs into phobos would be a great thing. Slightly slower AAs would be just fine for scripting and prototyping. > i believe that built-in AAs should be fast, but not necessarily featurefull. > and AAs with more features can be implemented in Phobos. With hindsight, I don't think AAs belong in a language as powerful as D. They should be done in the library. The dedicated syntax is nice, but minor. > > > yet i'm not sure that everyone are ready to pay 8/64 bytes per AA element > > > for this feature. > > Maybe not. > i certainly don't want that overhead. i done some work on faster byKey.first > though, see https://issues.dlang.org/show_bug.cgi?id=13410 Yeah, that's a similar tradeoff. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull CC||hst...@quickfur.ath.cx --- Comment #14 from hst...@quickfur.ath.cx --- Created a PR using Ketmar's patch: https://github.com/D-Programming-Language/druntime/pull/967 Thanks for contributing! --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #21 from Ketmar Dark --- (In reply to yebblies from comment #20) > Anyone looking for high performance in the built-in AAs is on the wrong track. but why? it's wrong to assume that AA has any defined order of items for iteration. this is *really* wrong. but there is nothing wrong with fast and memory-effective built-in AAs. why include language feature that is known to be slow when it can be reasonably fast? built-in AAs are very handy. and if they known to be slow, people will start to roll their own AA implementations virtually each time they want to use AA. and then we can just kill built-in AAs altogether. > Sure, but I tend to think of the builtin AAs as convenient but not > necessarily high performance. i believe that built-in AAs should be fast, but not necessarily featurefull. and AAs with more features can be implemented in Phobos. > > yet i'm not sure that everyone are ready to pay 8/64 bytes per AA element > > for this feature. > Maybe not. i certainly don't want that overhead. i done some work on faster byKey.first though, see https://issues.dlang.org/show_bug.cgi?id=13410 --
[Issue 13532] New: std.regex performance (enums; regex vs ctRegex)
https://issues.dlang.org/show_bug.cgi?id=13532
Issue ID: 13532
Summary: std.regex performance (enums; regex vs ctRegex)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: performance
Severity: enhancement
Priority: P5
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
I noticed something strange after accidentally introducing a performance
regression in a program using std.regex. Benchmark program:
///
import std.algorithm;
import std.array;
import std.conv;
import std.datetime;
import std.file;
import std.regex;
import std.stdio;
import std.string;
enum expr = `;.*`;
enum repl = "";
enum fn = `alice30.txt`;
enum N = 5000;
string[] lines;
void regexInline()
{
lines
.map!(line => line
.replaceAll(regex(expr), repl)
)
.array
;
}
void regexAuto()
{
auto r = regex(expr);
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
void regexStatic()
{
static r = regex(expr);
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
void regexEnum()
{
enum r = regex(expr);
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
void ctRegexInline()
{
lines
.map!(line => line
.replaceAll(ctRegex!expr, repl)
)
.array
;
}
void ctRegexAuto()
{
auto r = ctRegex!expr;
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
void ctRegexStatic()
{
static r = ctRegex!expr;
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
void ctRegexEnum()
{
enum r = ctRegex!expr;
lines
.map!(line => line
.replaceAll(r, repl)
)
.array
;
}
Regex!char re(string pattern)()
{
static Regex!char r;
if (r.empty)
r = regex(pattern);
return r;
}
void reInline()
{
lines
.map!(line => line
.replaceAll(re!expr, repl)
)
.array
;
}
alias funcs = TypeTuple!(
regexInline,
regexAuto,
regexStatic,
regexEnum,
ctRegexInline,
ctRegexAuto,
ctRegexStatic,
ctRegexEnum,
reInline,
);
void main()
{
auto text = cast(string)read(fn);
lines = text.splitLines();
auto results = benchmark!funcs(N);
foreach (i, func; funcs)
writeln(
__traits(identifier, func),
"\t",
to!Duration(results[i]),
);
}
///
Here are my results:
regexInline 10 secs, 174 ms, 254 μs, and 2 hnsecs
regexAuto 8 secs, 249 ms, 92 μs, and 5 hnsecs
regexStatic 8 secs, 155 ms, 231 μs, and 1 hnsec
regexEnum 19 secs, 358 ms, 66 μs, and 8 hnsecs
ctRegexInline 21 secs, 399 ms, 346 μs, and 5 hnsecs
ctRegexAuto 10 secs, 57 ms, and 418 μs
ctRegexStatic 10 secs, 66 ms, 489 μs, and 9 hnsecs
ctRegexEnum 21 secs, 593 ms, 486 μs, and 9 hnsecs
reInline8 secs, 430 ms, 852 μs, and 3 hnsecs
The first surprise for me was that declaring a regex object (either Regex or
StaticRegex) with "enum" was so much slower. It makes sense now that I think
about it: creating a struct literal inside a loop will be more expensive than
referencing one already residing somewhere in memory. Perhaps it might be worth
mentioning in the documentation to avoid using enum with compiled regexes.
The second surprise was that ctRegex was slower than regular regex, although
the difference is not significative.
I don't know whether this needs any action, feel free to WONTFIX.
--
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #20 from yebblies --- (In reply to hsteoh from comment #18) > > I think retaining insertion order is a needless overhead; if you needed such > a thing, it should be implemented in the library instead. Sure, but sometimes it's really handy. I've mostly wanted it when writing tests that accidentally relied on AA iteration order, which is perfectly stable unless you run the tests on different architectures. It's not a big deal but it's a nice user-friendliness thing. Anyone looking for high performance in the built-in AAs is on the wrong track. (In reply to Ketmar Dark from comment #19) > but you can implement your own AAs that does exactly this. built-in AAs > aren't *that* special, just some sugar here and there, plus some D code in > druntime. Sure, but I tend to think of the builtin AAs as convenient but not necessarily high performance. > actually, retaining insertion order will not be *that* slow, but you'll need > two more pointers for each inserted element. this will even make some use > cases faster (aa.byKey.first, for example, which is awfully slow now). > > yet i'm not sure that everyone are ready to pay 8/64 bytes per AA element > for this feature. Maybe not. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #19 from Ketmar Dark --- (In reply to yebblies from comment #14) > I'd love for the built-in AAs to use a linked hash map and guarantee > iteration in insertion order... but you can implement your own AAs that does exactly this. built-in AAs aren't *that* special, just some sugar here and there, plus some D code in druntime. actually, retaining insertion order will not be *that* slow, but you'll need two more pointers for each inserted element. this will even make some use cases faster (aa.byKey.first, for example, which is awfully slow now). yet i'm not sure that everyone are ready to pay 8/64 bytes per AA element for this feature. --
[Issue 12597] Payload getter for std.typecons.Typedef
https://issues.dlang.org/show_bug.cgi?id=12597
--- Comment #12 from bearophile_h...@eml.cc ---
(In reply to monkeyworks12 from comment #11)
> I think this enhancement request should be closed now that
> https://github.com/D-Programming-Language/phobos/pull/2116 has been merged.
> With that PR, your first example now becomes:
>
> void main() {
> import std.typecons: Typedef;
> import std.math: sin;
> alias Angle = Typedef!double;
> Angle x = 0.5;
> auto y1 = sin(x); // Error.
> auto y2 = sin(cast(TypedefType!Angle)x); // OK.
> }
>
> A bit verbose, but it accomplishes what you want and is more DRY and safer
> than cast(double)x.
This ER asks for a function like "typedefVal" that's usable like:
auto y2 = x.typedefVal.sin; // OK.
Casts are unsafe, their usage should be minimized in D code. So this ER is
still valid.
--
[Issue 10318] Built-in array sort usage warning, then deprecation, and finally removal
https://issues.dlang.org/show_bug.cgi?id=10318 --- Comment #10 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/ec670e5db9f386ae687458ceeb6bc0ebf5cc6f83 Merge pull request #669 from yebblies/issue10318 Do not use sort property directly --
[Issue 12433] Allow forward referencing IFTI types in template argument list
https://issues.dlang.org/show_bug.cgi?id=12433 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Related: issue #10228 --
[Issue 12386] Allow using derivatives of IFTI'd types in remaining arguments
https://issues.dlang.org/show_bug.cgi?id=12386 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #3 from hst...@quickfur.ath.cx --- Related: issue #10228 --
[Issue 10228] Type deduction fails with dependencies between parameter types
https://issues.dlang.org/show_bug.cgi?id=10228 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 9906] filter of static opCall
https://issues.dlang.org/show_bug.cgi?id=9906 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/phobos/pull/2556 --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #18 from hst...@quickfur.ath.cx --- +1 for 2. :-) Implementing reverse traversal for what's essentially an arbitrary order is meaningless at best, and gives a false sense of a non-existent fixed ordering. I think retaining insertion order is a needless overhead; if you needed such a thing, it should be implemented in the library instead. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #17 from yebblies --- (In reply to Steven Schveighoffer from comment #16) > (In reply to hsteoh from comment #12) > > It *is* possible to implement a reverse traversal in AA's. I'm just not sure > > it's a good idea (it'd need to allocate memory in order to traverse the > > linked-lists in reverse order). > > Or you could recurse :) > > Either way, you need memory. > > I think we have two legitimate options: > > 1. Fix foreach_reverse .byKey so it does the same thing as foreach > 2. Make foreach_reverse illegal on all cases of aa. > > I lean towards 2. > > The goal should be consistency. Making the thing actually work in reverse I > think is not possible. 2 is absolutely the answer. Basically copy-paste the error from the delegate foreach_reverse. The check should be the same, just in the Taarray block. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #16 from Steven Schveighoffer --- (In reply to hsteoh from comment #12) > It *is* possible to implement a reverse traversal in AA's. I'm just not sure > it's a good idea (it'd need to allocate memory in order to traverse the > linked-lists in reverse order). Or you could recurse :) Either way, you need memory. I think we have two legitimate options: 1. Fix foreach_reverse .byKey so it does the same thing as foreach 2. Make foreach_reverse illegal on all cases of aa. I lean towards 2. The goal should be consistency. Making the thing actually work in reverse I think is not possible. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #15 from bearophile_h...@eml.cc --- (In reply to yebblies from comment #14) > I'd love for the built-in AAs to use a linked hash map and guarantee > iteration in insertion order... It does have a performance hit on insertion > and deletion, but it is a really nice property for a default AA that isn't > super-optimized for any particular use case. In my opinion built-in data structures should be first of all very flexible (and keeping the insertion order is a guaranteed that makes them more useful). But in engineering as usual you have trade-offs. So how much is going to increase the memory and how much is going to decrease the performance with that added feature? In Python the built-in dict is fast, and there is an ordered dict in its standard library: https://docs.python.org/2/library/collections.html#collections.OrderedDict With a druntime function added I think you can implement ordered AAs for Phobos (based on the built-in ones) in an efficient way and a small amount of code, see Issue 10733 --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #14 from yebblies --- (In reply to bearophile_hugs from comment #13) > > Associative array pairs have a deterministic but undefined order. So what's > the reverse of an undefined order? I'd love for the built-in AAs to use a linked hash map and guarantee iteration in insertion order... It does have a performance hit on insertion and deletion, but it is a really nice property for a default AA that isn't super-optimized for any particular use case. > A simple solution is to turn > foreach_reverse on an associative array in a compile-time error. Yeah, that fits with the error we added for foreach_reverse on a delegate. AAs are special-cased in the compiler, should be easy enough to special-case an error for them. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 --- Comment #13 from bearophile_h...@eml.cc --- (In reply to hsteoh from comment #12) > It *is* possible to implement a reverse traversal in AA's. I'm just not sure > it's a good idea (it'd need to allocate memory in order to traverse the > linked-lists in reverse order). Associative array pairs have a deterministic but undefined order. So what's the reverse of an undefined order? A simple solution is to turn foreach_reverse on an associative array in a compile-time error. --
[Issue 10009] foreach_reverse and AA.byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=10009 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #12 from hst...@quickfur.ath.cx --- It *is* possible to implement a reverse traversal in AA's. I'm just not sure it's a good idea (it'd need to allocate memory in order to traverse the linked-lists in reverse order). --
[Issue 13489] Boolean semantics of floating point types should use "<> 0"
https://issues.dlang.org/show_bug.cgi?id=13489 --- Comment #6 from Leandro Lucarella --- (In reply to Leandro Lucarella from comment #5) > What the relation of signaling NaN and this. Will `if (nan)` raise a signal? Or any following use of nan afterwards, like `lround(fabs(x))`. f the > Maybe a runtime check is enough. > > It's clear that the code that raise this problem is buggy, no argue about > that, but how to fix it is not the topic of this issue, the topic is trying > to find a way to make the bug impossible to even exist, with help from the > language :) --
[Issue 13489] Boolean semantics of floating point types should use "<> 0"
https://issues.dlang.org/show_bug.cgi?id=13489 Leandro Lucarella changed: What|Removed |Added CC||leandro.lucarella@sociomant ||ic.com --- Comment #5 from Leandro Lucarella --- What the relation of signaling NaN and this. Will `if (nan)` raise a signal? Maybe a runtime check is enough. It's clear that the code that raise this problem is buggy, no argue about that, but how to fix it is not the topic of this issue, the topic is trying to find a way to make the bug impossible to even exist, with help from the language :) --
[Issue 13531] New: Destructor attributes don't take member destructor attributes into account
https://issues.dlang.org/show_bug.cgi?id=13531
Issue ID: 13531
Summary: Destructor attributes don't take member destructor
attributes into account
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: monarchdo...@gmail.com
If you have "S" with completely unsafe destructor, and you aggregate it into
"SS":
//
struct S
{
~this() //not nothrow, system, impure, gc etc...
{}
}
struct SS
{
S s;
~this() @safe pure nothrow @nogc
{}
}
//
This compiles. This may or may not be wrong, depending on your point of view:
The "code content" of the destructor is indeed actually safe etc...
The issue comes if you actually do try to use it in a safe context:
//
void main() @safe pure nothrow @nogc
{
SS ss;
}
//
Here is the error message:
//
Error: pure function 'D main' cannot call impure function 'main.SS.~this'
Error: safe function 'D main' cannot call system function 'main.SS.~this'
Error: @nogc function 'D main' cannot call non-@nogc function 'main.SS.~this'
Error: 'main.SS.~this' is not nothrow
Error: function 'D main' is nothrow yet may throw
//
The issue here is that it clearly states that "SS.~this" is the one that is
unsafe, yet it is clearly marked as such.
IMO, the bug is that it should have never been legally marked as @safe to begin
with.
--
[Issue 13489] Boolean semantics of floating point types should use "<> 0"
https://issues.dlang.org/show_bug.cgi?id=13489 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc --- The current D situation seems standard: http://stackoverflow.com/questions/9158567/nan-to-bool-conversion-true-or-false http://stackoverflow.com/questions/15686318/why-do-not-a-number-values-equal-true-when-cast-as-boolean-in-python-numpy --
[Issue 13529] std.string.lastIndexOf matches wrong element
https://issues.dlang.org/show_bug.cgi?id=13529 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/900c35c2603e8eb64ab10ba64042cda43212388a fix for issue13529 https://github.com/D-Programming-Language/phobos/commit/9e3591c09549df55777de947bfa38e93e341 Merge pull request #2554 from burner/issue13529 fix for issue13529 https://issues.dlang.org/show_bug.cgi?id=13529 --
[Issue 11888] Incorrect behaviour taking slice from return value
https://issues.dlang.org/show_bug.cgi?id=11888 Kenji Hara changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #5 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4026 --
