Re: Funny issue with casting double to ulong

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote:

6.251 has no perfect double representation. It's real value is:


 I almost wonder if a BCD, fixed length or alternative for 
floating point should be an option... Either library, or a hook 
to change how the FPU works since doubles are suppose to do 16-18 
digits of perfect simple floatingpoint for the purposes of money 
and the like without relying on such imperfect transitions.

Re: Funny issue with casting double to ulong

[Saurabh Das via Digitalmars-d-learn]

On Monday, 3 July 2017 at 03:57:25 UTC, Basile B wrote:

On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote:

[...]


6.251 has no perfect double representation. It's real value is:

6.215099962483343551867E0

Hence when you cast to ulong after the product by 10_000, this 
is the equivalent of


trunc(62150.99962483343551867E0)

which gives 62150

CQFD ;-]


That explains it!

Thank you.

Re: Funny issue with casting double to ulong

[Basile B via Digitalmars-d-learn]

On Monday, 3 July 2017 at 03:50:14 UTC, Saurabh Das wrote:

Consider this snippet:

void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);

auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}

The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151

Why does c round off from 62151 to 62150 when casting to ulong?

Thanks,
Saurabh


6.251 has no perfect double representation. It's real value is:

6.215099962483343551867E0

Hence when you cast to ulong after the product by 10_000, this is 
the equivalent of


trunc(62150.99962483343551867E0)

which gives 62150

CQFD ;-]

Funny issue with casting double to ulong

[Saurabh Das via Digitalmars-d-learn]

Consider this snippet:

void main()
{
import std.stdio;
auto a = 6.2151;
auto b = a * 1;
auto c = cast(ulong)b;
writeln("a: ", typeof(a).stringof, " ", a);
writeln("b: ", typeof(b).stringof, " ", b);
writeln("c: ", typeof(c).stringof, " ", c);

auto x = 62151.0;
auto y = cast(ulong)x;
writeln("x: ", typeof(x).stringof, " ", x);
writeln("y: ", typeof(y).stringof, " ", y);
}

The output is:
a: double 6.2151
b: double 62151
c: ulong 62150
x: double 62151
y: ulong 62151

Why does c round off from 62151 to 62150 when casting to ulong?

Thanks,
Saurabh

Re: Bulk allocation and partial deallocation for tree data structures.

[Stefan Koch via Digitalmars-d-learn]

On Monday, 3 July 2017 at 02:51:49 UTC, Filip Bystricky wrote:

Anyone?


The answer is no.

Partial deallocation in an arbitrary fashion is not advisable.

And there are no standard library mechanisms for it.

Re: Bulk allocation and partial deallocation for tree data structures.

[Filip Bystricky via Digitalmars-d-learn]

Anyone?

Re: Why do "const inout" and "const inout shared" exist?

[Walter Bright via Digitalmars-d]

On 7/2/2017 5:46 AM, Shachar Shemesh wrote:
Second, there are optimizations that can take place over "const" that cannot 
over "shared const" even assuming aliasing (such as if the compiler knows no 
other pointer was changed between two accesses).


The last point is that assuming no pointer aliasing is a fairly common 
optimization to take in C and C++, simply because of the huge performance gains 
it provides. It is so huge that it is sometimes turned on by default despite the 
fact it changes language semantics. It would be a pity to block any potential to 
have it in D.


Pointer aliasing is indeed a big deal for optimization.

But that really has nothing to do with const in C++. The trouble with C++ const 
is you can legally cast it away in C++. Chandler Carruth (LLVM optimizer) told 
me that const was basically ignored by the optimizer because of that.


D const is different in that the compiler is allowed to generate code as if 
const was never cast to immutable. Such casts are also not allowed in @safe code.

[Issue 13512] Allow non-UTF-8 encoding in shebang line

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13512

--- Comment #18 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/9f50d033696d686f00527a8b5f8efbb358fc2245
Fix Issue 13512 - Allow non-UTF-8 encoding in shebang line

Adapted from https://issues.dlang.org/attachment.cgi?id=1431=diff

https://github.com/dlang/dmd/commit/c25d606e7d8db7ed36218328eb37853c79902f39
Add test case for issue 13512

>From https://issues.dlang.org/attachment.cgi?id=1430

https://github.com/dlang/dmd/commit/48d5ef139b4d1aa874a3094bcccd16114c3f3349
Merge pull request #6959 from CyberShadow/pull-20170702-145440

Fix Issue 13512 - Allow non-UTF-8 encoding in shebang line 
merged-on-behalf-of: Andrei Alexandrescu <andra...@users.noreply.github.com>

--

[Issue 6554] windows case insensitive imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6554

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #2 from Vladimir Panteleev  ---
The error message is now much better:

test.d(4,12): Error: module std.bigint from file C:\...\std\bigInt.d must be
imported with 'import std.bigint;'

so I assume this can now be closed.

--

[Issue 17307] [REG2.072.0][ICE] TypeBasic::implicitConvTo: After error "anonymous struct can only be a part of an aggregate"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17307

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|[ICE]   |[REG2.072.0][ICE]
   |TypeBasic::implicitConvTo:  |TypeBasic::implicitConvTo:
   |After error "anonymous  |After error "anonymous
   |struct can only be a part   |struct can only be a part
   |of an aggregate"|of an aggregate"
   Severity|critical|regression

--- Comment #1 from Vladimir Panteleev  ---
This appears to be a regression.

Introduced in https://github.com/dlang/dmd/pull/5500

--

[Issue 10899] std.random.Random default RNG type should be customizable at compile-time

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10899

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
Hmm, I don't think this is going to be implemented, because...

- Historically the BDFLs have been opposed by compiler switches which change
program behaviour.

- Changing the RNG globally may break existing code which used Random with a
fixed seed.

- As you've mentioned,

(In reply to Joseph Rushton Wakeling from comment #0)
> Caveats: Could a build-local customization of Random have implications for
> linking?  I guess redefining the alias itself is not a problem but there
> could also be problems with clashes in the namespace for rndGen.

Random is an alias, so any symbols which have Random in their signature will
have different mangling (and fully-resolved type) depending on the compile-time
Random version selected.

- This bug is close to 4 years old with no replies, so I doubt someone is going
to start working on this now.

--

Re: Let's talk about deprecations

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 2 July 2017 at 23:27:26 UTC, Seb wrote:
1) Stop making such a fuzz about having a long deprecation 
period. Most people will only care about a deprecation when 
their project doesn't compile anymore. A deprecation period of 
two releases is more than enough for users that care. As seen 
even _eight_ releases don't help! (std.c was deprecated in 
2.067)


Long deprecation periods are really useful for situations where 
you need to support a wide range of compiler frontend versions 
(e.g. DMD and GDC, or whatever ancient D version is packaged on 
Debian/CentOS stable). They're also very helpful for regression 
testing, as you don't have to add static ifs all over just to 
test if the same otherwise effectively identical code worked in 
older compilers.


Once the relevant symbols are deprecated and removed from 
documentation, they have almost no cost, so there is no pressure 
to remove them quickly. I think overall it's more useful to leave 
old stuff around for longer rather than shorter amounts of time.

Re: Let's talk about deprecations

[Nicholas Wilson via Digitalmars-d]

On Sunday, 2 July 2017 at 23:27:26 UTC, Seb wrote:

Proposals
-

I think we should learn from the past. Here are a couple of 
ideas:


1) Stop making such a fuzz about having a long deprecation 
period. Most people will only care about a deprecation when 
their project doesn't compile anymore. A deprecation period of 
two releases is more than enough for users that care. As seen 
even _eight_ releases don't help! (std.c was deprecated in 
2.067)


The only concern I have with this is that not everyone uses DMD.
LDC typically lags the development cycle, although we try to keep 
up as fast as we can.
I'm no sure about the state of GDC though. I think Iain has it up 
to 2.072?
This makes it a pain for library writers who want to be 
compatible with all the compilers.




2) List deprecations in the changelog -


Do we not do this already?

users who care read it (and as seen there isn't any point to 
cater or wait for those who don't. I stress this point because 
people notoriously don't add their breaking changes to the 
changelog, which I guess has led to frustration & complains in 
the past and thus resulted in the currently cautious attitude 
against deprecations).
3) Ship a tool like dfmt with new releases that allows easy 
upgrades to new releases


Definitely!

4) Solve the problem automatically: let a bot that crawl _all_ 
D source code on GH and let it submits PRs for trivial 
deprecations (could be based on dfmt or other tools)


Ditto.

Especially with (3) (and optionally (4)) deprecations should 
become a lot less painless and they might again gain the glance 
of "awesome, we are getting rid of old, ugly stuff" instead 
"please don't break anything".


[#5532]: https://github.com/dlang/phobos/pull/5532
[#2337]: https://github.com/dlang/phobos/pull/2337
[dub]: https://github.com/dlang/dub/issues/1183
[tools]: https://github.com/dlang/tools/issues/238
[vibe.d]: https://github.com/rejectedsoftware/vibe.d/issues/1811

[Issue 17467] BitArray are broken with <<= 64

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17467

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Mac OS X|All

--

Let's talk about deprecations

[Seb via Digitalmars-d]

Hi all,

I think we need to talk about deprecations.
A recent example on [Phobos][#5532] uncovered an ugly truth: many 
people don't seem care about deprecation warnings.


#5532 wanted to remove the symbols scheduled for deprecation - 
most noteworthy here the removal of std.c.

FYI std.c was [deprecated  in September 2014][#2337].
Now, almost three years later, we have Martin's great project 
tester and for the first time we can assess the impact of turning 
deprecations into errors on the D ecosystem. The problem here is 
that the Project-Tester doesn't even get to the state of testing 
external projects, because it already fails on building 
[DUB][dub] and [rdmd][rdmd].
Without being able to see the failing, external projects on the 
Project-Tester I can only guess and with from looking at a few 
projects (e.g. [vibe.d][vibe.d]) it doesn't seem that there's fun 
ahead.


Proposals
-

I think we should learn from the past. Here are a couple of ideas:

1) Stop making such a fuzz about having a long deprecation 
period. Most people will only care about a deprecation when their 
project doesn't compile anymore. A deprecation period of two 
releases is more than enough for users that care. As seen even 
_eight_ releases don't help! (std.c was deprecated in 2.067)
2) List deprecations in the changelog - users who care read it 
(and as seen there isn't any point to cater or wait for those who 
don't. I stress this point because people notoriously don't add 
their breaking changes to the changelog, which I guess has led to 
frustration & complains in the past and thus resulted in the 
currently cautious attitude against deprecations).
3) Ship a tool like dfmt with new releases that allows easy 
upgrades to new releases
4) Solve the problem automatically: let a bot that crawl _all_ D 
source code on GH and let it submits PRs for trivial deprecations 
(could be based on dfmt or other tools)


Especially with (3) (and optionally (4)) deprecations should 
become a lot less painless and they might again gain the glance 
of "awesome, we are getting rid of old, ugly stuff" instead 
"please don't break anything".


[#5532]: https://github.com/dlang/phobos/pull/5532
[#2337]: https://github.com/dlang/phobos/pull/2337
[dub]: https://github.com/dlang/dub/issues/1183
[tools]: https://github.com/dlang/tools/issues/238
[vibe.d]: https://github.com/rejectedsoftware/vibe.d/issues/1811

Re: Phobos PR in need of review/merge

[Dukc via Digitalmars-d]

I see that my work has now been merged. Thanks for the effort 
everyone.


On Sunday, 2 July 2017 at 07:04:40 UTC, H. S. Teoh wrote:

Our goal was to cut it down to 25


I don't think the amount of open work is the problem. The metrics 
that matter IMO:


1. The time and likelihood to get a review after submitting a pr 
or completing changes requested to it. If the pr stalls because 
of the submitter, that does not matter. But if the tests pass and 
the reviewer has addressed all concerns, the less he has to push 
the reviewers the better.


2. Times one has to make changes before having the work accepted. 
The pr should not have to be perfect to get merged, but of course 
it must break nothing unless it's essential.


3. The likelihood of the work getting accepted at all, if pushed 
to the final decision. I think the state of that is good already: 
I have got nothing rejected what wasn't because I myself 
overlooked something.

[Issue 13980] We need better documentation for potential contributors

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13980

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Andrei Alexandrescu from comment #2)
> That's on POSIX. Is there a Windows equivalent yet?

https://wiki.dlang.org/Building_under_Windows ?

--

Re: Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 04:08 PM, Jack Stouffer wrote:

On Sunday, 2 July 2017 at 18:49:29 UTC, Walter Bright wrote:
Thank you. This explanation makes sense (given that applying const to 
immutable => immutable).


Since seemly everyone is confused about it, this topic looks like a 
great subject for a blog post.


We have top people on that (i.e. Timon!).

Also, I just improved the spec: 
https://github.com/dlang/dlang.org/pull/1787.



Andrei

[Issue 16999] takeOne popFront/Back does not pop the source range

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16999

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME
 OS|Windows |All

--- Comment #4 from Vladimir Panteleev  ---
PR was merged, so I assume this is now fixed.

--

[Issue 15870] UFCS not recognized on array when passing as alias parameter

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15870

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||CTFE, rejects-valid
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--

[Issue 14723] Typeinfo sent to GC does not retain storage class information

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14723

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
This looks like a very simple fix.

In Druntime, in rt.lifetime, in _d_newitemU, change:

auto blkInf = GC.qalloc(size, flags, ti);

to:

auto blkInf = GC.qalloc(size, flags, _ti);

If you still would like this changed, please submit a PR.

--

Re: std.string.format call from varyargs

[H. S. Teoh via Digitalmars-d-learn]

On Sun, Jul 02, 2017 at 11:38:34AM +0300, drug via Digitalmars-d-learn wrote:
> 02.07.2017 09:52, H. S. Teoh via Digitalmars-d-learn пишет:
[...]
> > Take a look at the docs that describe the "%(...%)" nested format
> > specifiers.  For example:
> > 
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(%s | %)", arr);
> > 
> > Output:
> > 
> > 1 | 2 | 3
> > 
> > Explanation: %(...%) means a nested format specifier, where the
> > stuff enclosed between %( and %) are applied to each array element
> > (actually, range element -- it works for arbitrary input ranges). In
> > this case, the stuff in between is "%s | ", which is treated as "%s"
> > followed by the delimiter " | ". So each array element is formatted
> > with %s, and " | " is inserted as a delimiter.
> > 
> > A slightly more interesting example:
> > 
> > int[] arr = [ 1, 2, 3 ];
> > writefln("%(<%s>%|, %)", arr);
> > 
> > Output:
> > 
> > <1>, <2>, <3>
> > 
> > Explanation: the stuff between %( and %) is "<%s>%|, ", which is
> > understood as applying "<%s>" to each array element, and treating ",
> > " as the delimiter. The "%|" separates the per-element component
> > from the delimiter; this distinction is important because we want
> > the ">" to appear after every element including the last one, but we
> > don't want the ", " to appear after the last element.
> > 
> > You can also nest %(...%) to handle multidimensional arrays. Here's
> > my favorite example:
> > 
> > auto m = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ];
> > writefln("%([ %(%s, %) ]%|\n%)", m);
> > 
> > Output:
> > 
> > [ 1, 2, 3 ]
> > [ 4, 5, 6 ]
> > [ 7, 8, 9 ]
> > 
> > Hope this helps!
[...]
> Cool! Is it D only or could be used in printf (C/C++)?

AFAIK, this is a D-specific extension.


T

-- 
Why do conspiracy theories always come from the same people??

Re: std.json cannot read an array floats back from file

[ketmar via Digitalmars-d-learn]

Yuri wrote:


Hi there,

consider the following simple use case:

   import std.json;
   float[] floats = [1,2,3];
   JSONValue j = "{}".parseJSON;
   j.object["floats"] = floats;
   std.file.write("test.json", j.toString);
   JSONValue jj = readText("test.json").parseJSON;
   jj.object["floats"].array[1].floating.writeln;

It is expected to print '2' in the console, however an exception is 
thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235): 
JSONValue is not a floating type


while the below works fine:

   import std.json;
   float[] floats = [1,2,3];
   JSONValue j = "{}".parseJSON;
   j.object["floats"] = floats;
   j.object["floats"].array[1].floating.writeln;

any pointers to what could be going wrong?


'cause what you got back is `JSON_TYPE.INTEGER`. dunno why it is there at 
all, as JSON has no "integers" per se, but it read as integer, and 
`.floating` failed type checking.


so, write your own wrapper that will convert INTEGER/UINTEGER/FLOAT to 
`double`. i think this is the best solution (if there can be "best 
solution" with std.json at all).

Re: std.json cannot read an array floats back from file

[Adam D. Ruppe via Digitalmars-d-learn]

On Sunday, 2 July 2017 at 21:07:40 UTC, Yuri wrote:
It is expected to print '2' in the console, however an 
exception is thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
 JSONValue is not a floating type



I think it just read the json string of "1" as being an integer 
instead of a float, so the reader thought it was integral instead 
of floating.


It should prolly just transparently auto-convert, but it doesn't 
seem to. Try accessing the int instead and see waht happens.

std.json cannot read an array floats back from file

[Yuri via Digitalmars-d-learn]

Hi there,

consider the following simple use case:

  import std.json;
  float[] floats = [1,2,3];
  JSONValue j = "{}".parseJSON;
  j.object["floats"] = floats;
  std.file.write("test.json", j.toString);
  JSONValue jj = readText("test.json").parseJSON;
  jj.object["floats"].array[1].floating.writeln;

It is expected to print '2' in the console, however an exception 
is thrown:


std.json.JSONException@/build/ldc-I3nwWj/ldc-0.17.1/runtime/phobos/std/json.d(235):
 JSONValue is not a floating type

while the below works fine:

  import std.json;
  float[] floats = [1,2,3];
  JSONValue j = "{}".parseJSON;
  j.object["floats"] = floats;
  j.object["floats"].array[1].floating.writeln;

any pointers to what could be going wrong?

Re: Boston D Meetup: Strawman Structs

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/2/17 6:35 AM, Steven Schveighoffer wrote:
I'll have a short presentation on a weird trick I discovered while 
writing some MySQL serialization code. Hope you can attend!


https://www.eventbrite.com/e/d-lang-presentation-strawman-structs-tickets-35120523431 


I've moved this to Friday to accommodate more people.

-Steve

Re: Go 1.9

[jmh530 via Digitalmars-d]

On Friday, 30 June 2017 at 20:36:47 UTC, bachmeier wrote:


An update. It looks like I will be able to get all of my 
research programs to work on Windows. It might be easier to use 
D in R packages on Windows than to use C/C++/Fortran because 
there is no need to mess with R tools, which many end users 
find confusing. The final piece of the puzzle would be an LDC 
installer for Windows that puts it in the path. Then it would 
definitely be easier to use D than C/C++/Fortran.


Cool. I still need to give embedrwin a try...

Re: Why do "const inout" and "const inout shared" exist?

[Jack Stouffer via Digitalmars-d]

On Sunday, 2 July 2017 at 18:49:29 UTC, Walter Bright wrote:
Thank you. This explanation makes sense (given that applying 
const to immutable => immutable).


Since seemly everyone is confused about it, this topic looks like 
a great subject for a blog post.

[Issue 17389] std.traits.hasNested fails for class with member of same type

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17389

--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/95f6d5bff36f2f951e0df6e899e92dc27e8311e8
Fix Issue 17389 - hasNested infinite recursion

Happens with a class with a member of the same type.

--

[Issue 17389] std.traits.hasNested fails for class with member of same type

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17389

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: Graph rendering on dlang.org

[Mark via Digitalmars-d]

On Saturday, 1 July 2017 at 20:53:07 UTC, Cym13 wrote:

On Saturday, 1 July 2017 at 19:19:09 UTC, Jonathan Marler wrote:
On Friday, 30 June 2017 at 21:40:05 UTC, Andrei Alexandrescu 
wrote:

[...]


There's also mermaid.  They have a live editor here: 
https://knsv.github.io/mermaid/live_editor/


[...]


Graphviz looks nicer both as diagram and markup honnestly; the 
separation in two halves make it harder to read for me compared 
to the more direct approach of graphviz.


My experience with GraphViz is that it's okay for simple, small 
diagrams but when I want to make something more complex it can be 
incredibly frustrating to make the digram look the way you want.


I didn't try Mermaid or any other visualization tools, though.

Re: regressions

[Brad Roberts via Digitalmars-d]

On 7/2/2017 7:27 AM, Vladimir Panteleev via Digitalmars-d wrote:

On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:

DMD, Phobos and Druntime open regressions over time:

http://bid.iline.cz/~mk/tmp/regs.png

Used to be stable, but seems to be getting worse since 2016.


One thing that might have contributed to that is that until a year or 
two ago, we weren't really checking whether filed bugs were 
regressions. As it turns out, a good deal of the time when someone 
runs into a bug, they don't even realize that it's some behaviour that 
used to work previously. This is why you will occasionally see 
recently-filed bugs that are marked as regressions in very old 
versions, likely older than since the submitter started using D.


Knowing whether a bug is a regression is useful because then you can 
track down the change that caused it, and it's often much easier to 
find the bug in a small diff and fix it. The downside is that it makes 
the meaning of the "regression" severity less useful when tracking how 
many of those issues actually broke someone's code (that we know 
about), which is why the regressing version is prefixed in issue 
summaries.


One of the biggest issues is that for a small period of time a few years 
ago, releases were actually gated on fixing regressions.  That stopped 
at some point and the backslide has gotten pretty bad. There was a 
period where there was exactly one open regression. It's one of my big 
disappointments in the current dev/release cycles.  That said, since I 
really haven't been participating in active development, I tend to just 
bite my tongue and say nothing. Holding to a line of no known 
regressions is a critical aspect of incrementally better releases.

[Issue 8293] Small amount of static analysis to avoid certain destructor bugs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8293

--- Comment #3 from Vladimir Panteleev  ---
(In reply to Marco Leise from comment #2)
> Which more or less means that if such an object is allocated with new, there
> must always be a pointer to it to prevent automatic collection. Because it
> has to be manually destroyed to be safe.
> Or can the GC be improved in this regard?

Just use C malloc. This is what RefCounted!T does.

--

[Issue 17237] Wrong alignment of 256-bit and 512-bit vectors

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17237

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16087

--

[Issue 16087] Alignment (.alignof) and stack space incorrect for SIMD types.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16087

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17237
 Resolution|--- |WORKSFORME

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Marco Leise from comment #0)
> writefln("float8.alignof yields %s but should yield 32.",
> float8.alignof);
> writefln("void16.alignof yields %s but should yield 16.",
> void16.alignof);

Fixed in https://github.com/dlang/dmd/pull/6265

> writefln("When embedded, a float4 exposes some hidden alignment, as it
> changes to %s.", Matrix4x4.alignof);

Fixed in https://github.com/dlang/dmd/pull/6582 (issue 17237)

--

Re: Why do "const inout" and "const inout shared" exist?

[Walter Bright via Digitalmars-d]

On 7/2/2017 6:33 AM, Timon Gehr wrote:
The best way to think about inout is that it enables a function to have three 
distinct signatures:


inout(int)[] foo(inout(int)[] arg);

"expands" to:

int[] foo(int[] arg);
immutable(int)[] foo(immutable(int)[] arg);
const(int)[] foo(const(int)[] arg);


const inout /does not change this in any way/:


const(inout(int))[] foo(inout(int)[] arg);

expands to:

const(int)[] foo(int[] arg);
const(immutable(int))[] foo(immutable(int)[] arg);
const(const(int))[] foo(const(int)[] arg);


Thank you. This explanation makes sense (given that applying const to immutable 
=> immutable).

[Issue 17586] New: Overriding a deprecated base class function gives no warning

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17586

  Issue ID: 17586
   Summary: Overriding a deprecated base class function gives no
warning
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

The following code should give a deprecation warning:

class C{
deprecated void foo(){}
}

class D: C{
override void foo(){}  
}

--

[Issue 17584] Wrong error message for deprecated overrides

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17584

timon.g...@gmx.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from timon.g...@gmx.ch ---
Accidentally created the issue twice.

--

[Issue 17585] New: Wrong error message for deprecated overrides

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17585

  Issue ID: 17585
   Summary: Wrong error message for deprecated overrides
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

The code:

class C{
void foo(){}
}

class D: C{
deprecated override void foo(){}  
}

Yields:

Deprecation: function tt.D.foo deprecated functions cannot be annotated
@disable

That is not what is happening. The error message should instead be:

Deprecation: overridden functions cannot be deprecated

--

[Issue 17584] New: Wrong error message for deprecated overrides

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17584

  Issue ID: 17584
   Summary: Wrong error message for deprecated overrides
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

The code:

class C{
void foo(){}
}

class D: C{
deprecated override void foo(){}  
}

Yields:

Deprecation: function tt.D.foo deprecated functions cannot be annotated
@disable

That is not what is happening. The error message should instead be:

Deprecation: overridden functions cannot be deprecated

--

Re: Why do "const inout" and "const inout shared" exist?

[Walter Bright via Digitalmars-d]

On 7/2/2017 2:34 AM, ag0aep6g wrote:

On 07/02/2017 10:55 AM, Walter Bright wrote:

If it is declared as:

 inout(char)[] foo(bool condition, inout(char)[] chars);

your specific case will work as expected. Perhaps you meant:


No, it doesn't. The function doesn't compile with that signature.


inout(char)[] foo(bool condition, inout(char)[] chars)
{
 if (!condition)
 return "condition failed!"; /* Error: cannot implicitly convert 
expression "condition failed!" of type string to inout(char)[] */

 return chars;
}



You're right.

[Issue 8570] Tuples without named fields should implicitly convert to tuples with named fields when returned from a function

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8570

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #2 from Vladimir Panteleev  ---
Reduced:

struct S { this(int) {} }

void bar()
{
S s = 5;
}

S foo()
{
return 5;
}

The first is an initialization / assignment; the second is an implicit
conversion. Currently D does not allow defining implicit conversions to
arbitrary types (closest is alias this, but it can alias only specific types).

Providing some way for types to do implicit conversions to arbitrary other
types is a much bigger discussion outside of the scope of this issue.

--

Re: Why do "const inout" and "const inout shared" exist?

[Walter Bright via Digitalmars-d]

On 7/2/2017 3:31 AM, Steven Schveighoffer wrote:

On 7/2/17 5:15 AM, Walter Bright wrote:

On 7/1/2017 3:12 PM, Timon Gehr wrote:

It used to be the case that const(inout(T)) = const(T),


Anyone want to run git bisect and see when this changed? This would help in 
figuring out the rationale.


Here's the code to test with it:

inout(const char)* foo(inout(const(char))* p)
{
 pragma(msg, typeof(p));
 static assert(is(typeof(p) == const(char)*));
 return p;
}


https://issues.dlang.org/show_bug.cgi?id=6930

-Steve


Ah, thanks to you and Vladimir! This is just what I wanted to see.

[Issue 13207] Wrong code for 'extern' C/C++ function returning struct

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13207

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #3 from Vladimir Panteleev  ---
These test cases are very badly incomplete. The C source code is incomplete, it
is at least missing includes to things obviously used in the presented code,
but I'm also getting numerous other errors. There are no command lines. There
are no compiler versions. There is no compiler or linker output.

I am closing this because this is very far from being reproducible and was
filed 3 years ago. Please reopen if you can post complete, self-contained,
reproducible test cases.

--

[Issue 5628] std.math unittest disabled - roundoff error in pow() on SSE2

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5628

--- Comment #6 from Vladimir Panteleev  ---
Here is the extracted test case from std.math:

void main()
{
import std.math;

immutable real x = 46;
immutable float xf = x;
immutable double xd = x;

immutable short neg2 = -2;
immutable long neg8 = -8;

assert(pow(xd, neg2) == 1 / (x * x));
assert(pow(xf, neg8) == 1 / ((x * x) * (x * x) * (x * x) * (x * x)));
}

--

[Issue 13060] @nogc reading an associative array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13060

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--- Comment #1 from Vladimir Panteleev  ---
If the index is not in the AA, then a RangeError is thrown. The error is
currently allocated on the GC heap.

The "in" operator is @nogc, though.

--

[Issue 14627] Implicit conversion from uint to dchar allows dchar > dchar.max

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14627

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P3
   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 6760] Disallow disabled overrides

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6760

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #6 from Vladimir Panteleev  ---
6570 was merged, so this looks fixed.

--

[Issue 16645] 3 errors messages instead of 1 after CTFE divide by 0

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16645

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
Introduced in https://github.com/dlang/dmd/pull/3602
Went from 3 to 2 errors in https://github.com/dlang/dmd/pull/6579
Fixed in https://github.com/dlang/dmd/pull/6917

--

[Issue 16200] Faster pow implementation for integral exponents

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16200

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
  Component|dmd |phobos
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Andrei Alexandrescu from comment #0)
> Stepanov discusses

(to clarify, that's Alex Stepanov, not related to D contributor Igor Stepanov)

--

[Issue 15582] Slice returned by opSlice() not accepted as lvalue

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15582

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 15368] Improve error message for "auto" keyword inside "foreach"

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15368

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic

--

[Issue 13470] Crash with final struct containing anonymous union

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13470

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
Incomplete testcase, no reply in 2 years, closing.

--

[Issue 8995] `is( == function)` creates tuple with parameter storage classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8995

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||spec
 CC||dlang-bugzilla@thecybershad
   ||ow.net

--

[Issue 8995] `is( == function)` creates tuple with parameter storage classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=8995

Vladimir Panteleev  changed:

   What|Removed |Added

 CC|dlang-bugzilla@thecybershad |
   |ow.net  |

--

[Issue 12059] Smarter error messages when a module contains a namespace with the same name

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12059

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |DUPLICATE

--- Comment #2 from Vladimir Panteleev  ---
The error message was improved in https://github.com/dlang/dmd/pull/4510.

*** This issue has been marked as a duplicate of issue 14320 ***

--

[Issue 14320] Improve diagnostic message for "undefined identifier" error

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14320

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc

--- Comment #4 from Vladimir Panteleev  ---
*** Issue 12059 has been marked as a duplicate of this issue. ***

--

[Issue 12068] `enum` as `inout` function parameter isn't enough for `inout` return.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12068

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15762
 Resolution|--- |WORKSFORME

--- Comment #2 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/5878.

--

[Issue 15762] Array casts involving const enums can be made @safe

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15762

Vladimir Panteleev  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12068

--

[Issue 16674] Clarify lifetime of pointer to AA entry

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16674

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||spec

--

[Issue 16968] Error.bypassedException is always null

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16968

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull
 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
I see https://github.com/dlang/druntime/pull/1712 is merged, closing.

--

[Issue 15505] extern(C++) array parameter mangling gains surprise const

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15505

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||C++
   Hardware|x86_64  |All
   Severity|enhancement |normal

--- Comment #1 from Vladimir Panteleev  ---
Only occurs when targeting the MS toolchain (-m64 / -m32mscoff).

-m32mscoff:
mangled: ?f@@YAXQAY03H@Z
demangled: void __cdecl f(int (* const)[4])

-m64:
mangled: ?f@@YAXQEAY03H@Z
demangled: void __cdecl f(int (* __ptr64 const)[4])

--

[Issue 6207] Mixin template evaluated to string can convert to string mixin expression implicitly

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=6207

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Walter Bright from comment #3)
> See the pull request for more discussion.

I believe such a change today would require a DIP, so I'm going to close this.

--

[Issue 12239] "undefined identifier" with named import and circular reference

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12239

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/5333.

*** This issue has been marked as a duplicate of issue 15519 ***

--

[Issue 15519] Circular imports leads to fwd ref error with aliased imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15519

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #5 from Vladimir Panteleev  ---
*** Issue 12239 has been marked as a duplicate of this issue. ***

--

[Issue 17080] Can assign member-function-ptr to free-function-ptr

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17080

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 2484] Templated classes have no moduleinfo

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2484

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86 |All
 Resolution|--- |WONTFIX
 OS|Windows |All

--- Comment #9 from Vladimir Panteleev  ---
I believe we are moving away from Object.factory, so I doubt anything major
will change here.

Today, D's introspection capabilities allow building reflection information at
compile-time and using it at run-time, thus allowing users to build their own
Object.factory equivalents with the capabilities they need.

--

[Issue 15892] Can't use alias this with static namespaces

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15892

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--

[Issue 10317] (2.063): Recursive error within Phobos

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10317

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #10 from Vladimir Panteleev  ---
(In reply to Andrej Mitrovic from comment #9)
> The library fix is in place, but we still have to figure out why 2.062
> doesn't exhibit the same behavior even though it has the same library code.
> So I'm downgrading this to a normal bug to avoid blocking the .2 release

As no reproducible test case has materialized in the past 4 years, closing.

FWIW, this regression was initially introduced in
https://github.com/dlang/dmd/pull/1760.

--

Re: D and .lib files. C++/Other?

[Damien Gibson via Digitalmars-d-learn]

Ahh, you need to initialise the D runtime before you call any 
functions that depend on it (e.g. ones that interact with the 
file system).


declare
extern "C" int rt_init();
in your c++ code and call it before ConsoleWrite and it should 
work.


Honestly i did try this and it didnt correct the problem... 
HOWEVER... I had been deleting the dll page VS and Xamarin always 
generate with a shared dll project as since i got dlls working 
with D in the first place(I was slow to figure it out) it worked 
just fine without the dllmain page they generated...


Placing that back in there now that weve come this far corrected 
the problem-> Without the need to even write rt_init in D or C++.


Thank you both very much for the help and information you guys 
have provided this problem is finally solved!


___
IF anyone happens to come across this thread in the future and 
has the same problem i did -> Note: Probably involving the use of 
Xamarin/MonoDevelop or Visual Studio with dll creation or 
compatibility with C++ I'd be happy to create a couple of sample 
projects and list the stuff it required me to install for it all 
to work.


I'm not going to do that at this moment as since I had to ask it 
seems i MAY be the only moron who seemed to have this issue? 
Anyway Bye everyone!

[Issue 17004] std.containers should be usable with @nogc

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17004

Vladimir Panteleev  changed:

   What|Removed |Added

  Component|installer   |phobos
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17583] New: Revive tools/pr/194 - compile the root module in the same step as getting the dependencies

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17583

  Issue ID: 17583
   Summary: Revive tools/pr/194 -  compile the root module in the
same step as getting the dependencies
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

The PR https://github.com/dlang/tools/pull/194 got reverted due to a
regression. As rdmd is a widely used tool reviving it would have a positive
impact on many people.

FWIW it seems that integrating rdmd into dmd is still far ahead in the future.

--

[Issue 12802] Allow optional 'StorageClasses' for new alias syntax

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12802

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #5 from Vladimir Panteleev  ---
*** Issue 12055 has been marked as a duplicate of this issue. ***

--

[Issue 12055] Error: basic type expected, not extern when using 'alias = function'

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12055

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |DUPLICATE

--- Comment #3 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/3585.

*** This issue has been marked as a duplicate of issue 12802 ***

--

[Issue 15648] Destructor constness doesn't take member destructor attributes into account

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15648

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
I believe the operation destroy(x) where x is an immutable value type was never
supported, as part of destroy's operation is to clobber the value of x with its
.init value - see object.d, the `void destroy(T)(ref T obj) if (is(T ==
struct))` overload. 

Changing the destroy() call with an explicit invocation of the inclusive
destructor (`keys[0].__xdtor();`) does seem to illustrate the problem better, I
think - the inclusive destructor should have its constness inferred from the
destructors it calls:

$ cat test.d 
struct HashTable
{
immutable(Key)* keys;

~this()
{
keys[0].__xdtor();
}
}

struct Key
{
KeyData data;
~this() const {}
}

struct KeyData
{
~this() const {}
}

$ dmd -o- test.d
test.d(7): Error: mutable method test.Key.~this is not callable using a
immutable object

--

[Issue 13512] Allow non-UTF-8 encoding in shebang line

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13512

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #17 from Vladimir Panteleev  ---
https://github.com/dlang/dmd/pull/6959

--

[Issue 13512] Allow non-UTF-8 encoding in shebang line

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13512

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|dmd cannot compile  |Allow non-UTF-8 encoding in
   |perfectly valid code with   |shebang line
   |shebang |

--

[Issue 9360] Bad error message with non-const template method

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9360

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 Resolution|--- |WORKSFORME
 OS|Windows |All

--- Comment #1 from Vladimir Panteleev  ---
Since https://github.com/dlang/dmd/pull/1409, the error message now mentions
const, so this should be clearer.

--

[Issue 9086] std.typecons.appendIfNotNull() or a better idea

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=9086

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #4 from Vladimir Panteleev  ---
(In reply to bearophile_hugs from comment #0)
> A problem with std.typecons.Nullable is that the D type system is not
> powerful enough to see this is correct code:

This example now compiles fine.

Fixed in https://github.com/dlang/phobos/pull/1103

--

[Issue 17246] [REG2.053] Extra destructor call.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17246

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|Extra destructor call.  |[REG2.053] Extra destructor
   ||call.
   Severity|critical|regression

--- Comment #1 from Vladimir Panteleev  ---
Same example with asserts replacing writelns, and checks based on simple
reference counting:

struct Foo
{
int* rc;
this(int val)
{
rc = new int;
(*rc) = 1;
}
this(this)
{
(*rc)++;
}
~this()
{
if (rc)
{
assert(*rc > 0);
(*rc)--;
}
}
}

struct Bar
{
Foo foo;
this(Foo foo, bool)
{
this.foo = foo;
}
}

bool fun(bool val) { return !val; }

auto genBar(bool flag)
{
return flag ? Bar() : Bar(Foo(10), fun(!flag));
}

void main(string[] args)
{
auto bar = genBar(args.length == 0);
}

This appears to be a regression, as it worked before 2.052.

Introduced in
https://github.com/dlang/dmd/commit/e764b3949ae0f95f8fc4d7d2e9114e29fee12493

--

Re: regressions

[Vladimir Panteleev via Digitalmars-d]

On Friday, 30 June 2017 at 12:48:12 UTC, Martin Krejcirik wrote:

DMD, Phobos and Druntime open regressions over time:

http://bid.iline.cz/~mk/tmp/regs.png

Used to be stable, but seems to be getting worse since 2016.


One thing that might have contributed to that is that until a 
year or two ago, we weren't really checking whether filed bugs 
were regressions. As it turns out, a good deal of the time when 
someone runs into a bug, they don't even realize that it's some 
behaviour that used to work previously. This is why you will 
occasionally see recently-filed bugs that are marked as 
regressions in very old versions, likely older than since the 
submitter started using D.


Knowing whether a bug is a regression is useful because then you 
can track down the change that caused it, and it's often much 
easier to find the bug in a small diff and fix it. The downside 
is that it makes the meaning of the "regression" severity less 
useful when tracking how many of those issues actually broke 
someone's code (that we know about), which is why the regressing 
version is prefixed in issue summaries.

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 10:12, Sönke Ludwig wrote:

So I'd probably still opt for simplifying the conversion hierarchy.


It may indeed be a good idea to completely remove inout from the 
conversion hierarchy in the documentation:


   const   const shared
  / \  / \
(unqualified)   immutable   shared

The extended hierarchy can be presented in the inout documentation 
alongside its derivation from the standard conversion hierarchy.

[Issue 2005] dynamic va_arg looping/ align info in TypeInfo

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2005

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
As I understand, C-style variadics are provided in D only as a low-level
interoperability feature with existing C code. Today, variadic IFTI template
functions should be used instead in D code.

(In reply to Fawzi Mohamed from comment #0)
> Such functions could be readily implemented for dmd if typeinfo would give
> access to the alignment information of its type (.talign?).

TypeInfo.talign was added in
https://github.com/dlang/druntime/commit/cbd538f34f8082cc512a05eae3ab23039d8fe1d7.

--

Re: Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 10:00 AM, Timon Gehr wrote:

On 02.07.2017 15:33, Timon Gehr wrote:

On 02.07.2017 10:55, Walter Bright wrote:

Neither I nor anyone here seems to understand its purpose.


The opposite is true. I understand it, and you seem to understand it 
partially:


Also, there are actually at least two other people in this thread who 
have demonstrated their understanding. So I count two confused people 
and three people who are not confused. Still not a great ratio, but I'll 
try to improve it with a blog post.


That's fantastic, Timon. Thanks in advance! -- Andrei

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 15:33, Timon Gehr wrote:

On 02.07.2017 10:55, Walter Bright wrote:

Neither I nor anyone here seems to understand its purpose.


The opposite is true. I understand it, and you seem to understand it 
partially:


Also, there are actually at least two other people in this thread who 
have demonstrated their understanding. So I count two confused people 
and three people who are not confused. Still not a great ratio, but I'll 
try to improve it with a blog post.

[Issue 13471] CTFE glitch when executing std.digest.crc.crc32Of() and checking the result with enforce(). (keyword: uninitialized variable)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13471

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic

--

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 15:48, Andrei Alexandrescu wrote:

On 07/02/2017 09:39 AM, Timon Gehr wrote:
In general, depending on the hardware memory model and the language 
memory model, data transfer from one thread to another requires 
cooperation from both parties. We don't want the thread that has the 
unshared data to need to participate in such a cooperation.


Yes, there must be a handshake. Oh, I see your point. Let me illustrate:

void fun(const shared int* p1)
{
auto a = atomicLoad(p1);
...
}

void gun()
{
 int* p = new int;
 shared const int* p1 = p; // assume this passes
 spawn(, p);
 *p = 42; // should be a shared write, it's not
}

Is this what you're referring to?
...


Yes, precisely.

So it seems like the hierarchy in http://erdani.com/conversions.svg is 
minimal?




Yes, I think there is no way to collapse it without bad consequences.

[Issue 16621] [REG2.060] DMD hang in semantic3 on alias this or segfault

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16621

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
Summary|DMD hang in semantic3 on|[REG2.060] DMD hang in
   |alias this or segfault  |semantic3 on alias this or
   ||segfault
   Severity|major   |regression

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Daniel Kozak from comment #0)
> hang code example:

This one seems to be a regression.

Introduced in https://github.com/dlang/dmd/pull/890

> segfault example:

This one was always there.

--

[Issue 15868] Inappropriate error message: "base type must be class or interface" (and it is)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15868

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |DUPLICATE

--- Comment #1 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/5333.

*** This issue has been marked as a duplicate of issue 15519 ***

--

[Issue 15519] Circular imports leads to fwd ref error with aliased imports

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15519

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||andy.pj.han...@gmail.com

--- Comment #4 from Vladimir Panteleev  ---
*** Issue 15868 has been marked as a duplicate of this issue. ***

--

Re: Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 09:49 AM, Andrei Alexandrescu wrote:

On 07/02/2017 09:48 AM, Andrei Alexandrescu wrote:

 *p = 42; // should be a shared write, it's not


I meant:

 p = new int; // should be a shared write, it's not


Dognabbit. No, I meant the previous one! The pointer itself is private 
to gun. -- Andrei

Re: Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 09:48 AM, Andrei Alexandrescu wrote:

 *p = 42; // should be a shared write, it's not


I meant:

p = new int; // should be a shared write, it's not


Andrei

Re: Why do "const inout" and "const inout shared" exist?

[Andrei Alexandrescu via Digitalmars-d]

On 07/02/2017 09:39 AM, Timon Gehr wrote:
In general, depending on the hardware memory model and the language 
memory model, data transfer from one thread to another requires 
cooperation from both parties. We don't want the thread that has the 
unshared data to need to participate in such a cooperation.


Yes, there must be a handshake. Oh, I see your point. Let me illustrate:

void fun(const shared int* p1)
{
   auto a = atomicLoad(p1);
   ...
}

void gun()
{
int* p = new int;
shared const int* p1 = p; // assume this passes
spawn(, p);
*p = 42; // should be a shared write, it's not
}

Is this what you're referring to?

So it seems like the hierarchy in http://erdani.com/conversions.svg is 
minimal?



Andrei

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 14:31, Andrei Alexandrescu wrote:

On 07/02/2017 02:49 AM, Shachar Shemesh wrote:

On 02/07/17 02:08, Andrei Alexandrescu wrote:
Vaguely related question: should "const" convert implicitly to "const 
shared"? The intuition is that the latter offers even less guarantees 
than the former so it's the more general type. See 
http://erdani.com/conversions3.svg.


I don't see how it can. They provide different guarantees. If 
anything, it should be the other way around.


If you hold a pointer to const, you know the data will not change 
during the function's execution. No such guarantees for const shared.


That supports the case for allowing the conversion.

const: "You have a view to data that this thread may or may not change."

const shared: "You have a view to data that any thread may or may not 
change."


So the set of const is included in the set of const shared - texbook 
inclusion polymorphism.


This is not the whole story. The best way to think about 'shared' is 
that it enables guarantees about data that does /not/ have the 
qualifier. So we need to look at what this change does to the meaning of 
data being unqualified:


It changes from:

unqualified: This data can be read and written exclusively by the 
current thread.


to

unqualified: This data can be read and written by this thread and read 
by any other thread.



This disallows some program transformations that were allowed before 
unless reading from a const shared reference while a mutable thread is 
writing to it has an undefined result, in which case the change just 
removes /all/ guarantees from const shared just in order to place it at 
the top of the hierarchy. At this point you can just use void*.

[Issue 7443] Better diagnostic on wrongly written static constructor

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7443

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid,
   ||link-failure
 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Severity|enhancement |normal

--- Comment #1 from Vladimir Panteleev  ---
To clarify, the example given currently (wrongly) compiles but fails to link
due to a "multiple definition" error.

Upgrading from enhancement since it seems like an accepts-invalid.

--

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 15:29, Andrei Alexandrescu wrote:

On 07/02/2017 09:07 AM, Timon Gehr wrote:

On 02.07.2017 14:41, Andrei Alexandrescu wrote:

On 07/01/2017 07:55 PM, Timon Gehr wrote:

On 02.07.2017 01:08, Andrei Alexandrescu wrote:
Vaguely related question: should "const" convert implicitly to 
"const shared"? The intuition is that the latter offers even less 
guarantees than the former so it's the more general type. See 
http://erdani.com/conversions3.svg.


That would be nice because we have "const shared" as the unique 
root of the qualifier hierarchy.


This means that there can be aliasing between an unqualified 
reference and a const shared reference. Therefore, you can have code 
that mutates unshared data while another thread is reading it.


What should the semantics of this be?

The only potential issue is that it could restrict code operating on 
unshared data because it needs to play nice in some way to allow 
consistent data to be read by another thread.


Well const shared exists already with the semantics of "you can't 
modify this and you must load it atomically to look at it". The 
question is whether the conversion from const to const shared can be 
allowed. -- Andrei


If the data is not written atomically, how can it be loaded atomically?


Then you atomically load parts of it, the point being that the matter is 
present in the type. I must not be understanding the question. -- Andrei


In general, depending on the hardware memory model and the language 
memory model, data transfer from one thread to another requires 
cooperation from both parties. We don't want the thread that has the 
unshared data to need to participate in such a cooperation.

[Issue 13532] std.regex performance (enums; regex vs ctRegex)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13532

--- Comment #6 from Vladimir Panteleev  ---
2017 timings with LDC 1.2.0 (DMD v2.072.2, LLVM 4.0.0):

regexInline7 secs, 342 ms, 775 μs, and 9 hnsecs
regexAuto5 secs, 195 ms, and 526 μs
regexStatic5 secs, 158 ms, 479 μs, and 2 hnsecs
regexEnum18 secs, 777 ms, 420 μs, and 7 hnsecs
ctRegexInline20 secs, 38 ms, and 25 μs
ctRegexAuto6 secs, 16 ms, 155 μs, and 1 hnsec
ctRegexStatic5 secs, 921 ms, 572 μs, and 3 hnsecs
ctRegexEnum20 secs, 422 ms, 889 μs, and 4 hnsecs
reInline5 secs, 84 ms, 943 μs, and 1 hnsec

--

[Issue 10810] wrong forward reference error when using return type deduction and a cyclic call flow

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10810

--- Comment #6 from timon.g...@gmx.ch ---
(In reply to Vladimir Panteleev from comment #5)
> (In reply to timon.gehr from comment #3)
> > Currently, this is quite conservative. Analysis of any function is suspended
> > if a function call with unresolved return type is encountered, until this
> > return type has been resolved.
> 
> Short-circuiting return type analysis to "void" if there are no return
> statements in the body seems like a reasonable way to solve this particular
> case to me.

The compiler does not know whether there are any return statements in the body
when starting the analysis of a function because of conditional compilation and
string mixins.

--

Release fluent-asserts 0.6.0

[Szabo Bogdan via Digitalmars-d-announce]

Hi,

I just made a new release of fluent-asserts:

http://fluentasserts.szabobogdan.com/
https://code.dlang.org/packages/fluent-asserts

Since my last announcement I improved the library with:
 - better error messages
 - better exception api
 - integration with ranges
 - new asserts `executionTime` for callable and `containsOnly` 
for ranges
 - a new `Assert` utility for those who don't like the BDD style 
of writing asserts


Any feedback is appreciated.

Thanks,
Bogdan

Re: Why do "const inout" and "const inout shared" exist?

[Timon Gehr via Digitalmars-d]

On 02.07.2017 10:55, Walter Bright wrote:

Neither I nor anyone here seems to understand its purpose.


The opposite is true. I understand it, and you seem to understand it 
partially:


On 02.07.2017 05:55, Walter Bright wrote:

On 7/1/2017 6:22 PM, Stefan Koch wrote:

I cannot think so a single time I ever used const inout.


The math needs to work whether it is ever used or not, otherwise we wind 
up with bizarre, intractable absurdities.




It's my fault as I should have noticed this getting slipped into the compiler. 


No, it is Kenji Hara's and my achievement. This is one of the things 
Kenji slipped into the language that actually should be there. If you 
have 'inout' there is no way around 'const inout'.


The existence of it is likely a significant contributor to peoples' 
confusion about inout.


The opposite is true. Many people are confused about inout and by 
extension about const inout.


The best way to think about inout is that it enables a function to have 
three distinct signatures:


inout(int)[] foo(inout(int)[] arg);

"expands" to:

int[] foo(int[] arg);
immutable(int)[] foo(immutable(int)[] arg);
const(int)[] foo(const(int)[] arg);


const inout /does not change this in any way/:


const(inout(int))[] foo(inout(int)[] arg);

expands to:

const(int)[] foo(int[] arg);
const(immutable(int))[] foo(immutable(int)[] arg);
const(const(int))[] foo(const(int)[] arg);

It would be confusing if it worked any differently.