[Issue 16724] RandomCover.popFront is a no-op for the first call

[via Digitalmars-d-bugs]

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

Joseph Rushton Wakeling  changed:

   What|Removed |Added

 CC||joseph.wakel...@webdrake.ne
   ||t

--- Comment #5 from Joseph Rushton Wakeling  ---
Sorry to have missed this, but the fix is itself broken, because it strips out
the lazy `front` of `randomCover`.

First, random algorithms (like random cover) ideally need to have a truly lazy
initial `front` value, otherwise you can run into trivial errors like:

   auto arr = [1, 2, 3, 4, 5];
   auto cover = arr.randomCover;
   cover.writeln;  // three 'different' covers
   cover.writeln;  // but each of them with
   cover.writeln;  // the same first value

... so the check on already-chosen elements in `front` wasn't there by accident
(although it may have needed further work in how it was implemented).

Second, I just tried running the above right now and got a never-ending stream
of `5, 5, 5, 5, 5, ...` out of my computer before I killed it.  So I'm not sure
that this new randomCover is working right at all :-(

--

[Issue 17174] can take address of member of struct parameter in @safe code

[via Digitalmars-d-bugs]

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

--- Comment #2 from Alex  ---
@ag0aep6g
Ok... my complaint was about your first two lines. Didn't take this into
account. 
But even then, it seems strange to me to be able to take a pointer to a value
parameter, in any case...
With other words: 
The treatment I was wondering about (allocating memory) is needed, and I should
have known this, because the constructor is not marked as @safe.

--

[Issue 16442] FrontTransversal fails with empty ranges

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/41c2d14658817419cb335a42656130b7aa2959f6
Fix Issue 16442 - FrontTransversal fails with empty ranges

https://github.com/dlang/phobos/commit/68c77e1358050443ac295a60812055a56c70ff84
Merge pull request #5091 from RazvanN7/Issue_16442

Fix Issue 16442 - FrontTransversal fails with empty ranges

--

[Issue 17154] std.conv.toChars doesn't support $ in slicing

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 17154] std.conv.toChars doesn't support $ in slicing

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/d5ae07f0f125bdefe92b4035dfb35f613dbf9a8a
Fix Issue 17154 - Added opDollar to std.conv.toChars

https://github.com/dlang/phobos/commit/d8ca218d540a1c938bb36f70f0ee36388bce85aa
Merge pull request #5081 from dlang/JackStouffer-patch-2

Fix Issue 17154 – Add opDollar to std.conv.toChars

--

[Issue 5813] [patch] std.array.Appender has severe performance and memory leak problems.

[via Digitalmars-d-bugs]

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

--- Comment #22 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/5115

--

[Issue 17174] can take address of member of struct parameter in @safe code

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||accepts-invalid, safe
 CC||ag0ae...@gmail.com
   Hardware|x86 |All
Summary|auto ref allows pointers to |can take address of member
   |rvalues |of struct parameter in
   ||@safe code
 OS|Mac OS X|All

--- Comment #1 from ag0ae...@gmail.com ---
Taking the address of a value parameter is allowed in @system code. Your
constructor is not marked as @safe, so it's @system and you're allowed to do
that.

However, if you add @safe, the code still compiles. That's a bug. It doesn't
seem to be related to `auto ref`, though. Rather, the compiler gets confused by
the struct. I'm changing the summary of this issue to be about this.


/* Shouldn't compile: */
void f(initStruct iS) @safe
{
auto p =  /* Should trigger the same error as below. */
}

struct initStruct
{
size_t var;
}

/* Doesn't compile, as it should be: */
void g(size_t var) @safe
{
auto p =  /* "Error: cannot take address of parameter" */
}


--

[Issue 17174] auto ref allows pointers to rvalues

[via Digitalmars-d-bugs]

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

Alex  changed:

   What|Removed |Added

 CC||sascha.or...@gmail.com

--

[Issue 17174] New: auto ref allows pointers to rvalues

[via Digitalmars-d-bugs]

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

  Issue ID: 17174
   Summary: auto ref allows pointers to rvalues
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

As discussed here: 
https://forum.dlang.org/post/uxznyrmmtptmzucjc...@forum.dlang.org

tested with 2.073.0 on a mac. 

// Code starts here
void main()
{
initStruct iSb;
iSb.var = 3;
A b = A(iSb);
assert(*b.myVar == 3); // this works
iSb.var = 4;
assert(*b.myVar == 4); // as expected

b = A(initStruct(5)); // how does
assert(*b.myVar == 5); // this work?
}

struct A
{
@disable this();
size_t* myVar;
this()(auto ref initStruct iS) @nogc
{
import core.stdc.stdio;
__traits(isRef, iS) ? printf("ref case\n") : printf("value case");

myVar = 

/* // This treatment is not needed?
if(__traits(isRef, iS))
{
myVar = 
}
else
{
myVar = new size_t(iS.var);
}
*/
}
}

struct initStruct
{
size_t var;
}
// Code ends here

In case of initializing an A-instance with an rvalue, it should be a
compile-time error to get a pointer to the parameter.

--

[Issue 17131] [Reg 2.074] Fiber.state collides with differently attributed function in derived class

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17130] [Reg 2.074] ambiguous implicit super call when inheriting core.sync.mutex.Mutex

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/db81df0b6db19f5808e551a01730c15d341dc981
fix Issue 17130 - ambiguous implicit super call

- need type of this to resolve base class ctor overloads

https://github.com/dlang/dmd/commit/5262d78df2d2b4b3ee1fffc3393a5d57b535a481
Merge pull request #6513 from MartinNowak/fix17130

fix Issue 17130 - ambiguous implicit super call

--

[Issue 17173] New: Incorrect return value for function accepting and returning cdouble

[via Digitalmars-d-bugs]

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

  Issue ID: 17173
   Summary: Incorrect return value for function accepting and
returning cdouble
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: meapineap...@gmail.com

This code behaves correctly when compiling with DMD v2.072.0 on Win7. It
behaves incorrectly with the same DMD version on OSX.

import std.stdio;

auto fn(in cdouble value){
writeln(value.re + 0i); // Prints 64+0i
return value.re + 0i;
}

unittest{
writeln(fn(64 + 0i)); // Prints 64+64i, should print 64+0i
}

It behaves correctly if:

If writeln is removed from fn (In the case where I encountered this bug, there
was other essential code but no writeln, I don't think this is related to
writeln specifically)

If an empty out contract is added to fn

--

[Issue 17162] std.algorithm.startsWith fails to compile with -dip1000 switch

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Hardware|x86_64  |All
 OS|Windows |All
   Severity|regression  |normal

--- Comment #1 from Jack Stouffer  ---
Unfortunately, all of Phobos doesn't compile with DIP1000. This is labeled an
experimental feature for a reason.

This is not a regression by definition, because this functionality did not
exist before.

--

[Issue 17171] ddoc: enum misses some values + wrong order + missing member initializers

[via Digitalmars-d-bugs]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #1 from Jacob Carlborg  ---
(In reply to Timothee Cour from comment #0)

> * A1 the `none` entry doesn't appear.

As far as I can see, "none" is not documented.

--