[Issue 18244] Generic functions in std.math cannot be overloaded

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18244

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

https://github.com/dlang/phobos/commit/113579ec6be26777198a2e13abe9913226a385e6
Fix issue 18244: Generic functions in std.math need to have proper sig
constraints.

Not having any sig constraints causes needless conflicts with
user-defined numerical types, e.g.:


// myNumber.d
module myNumber;
struct MyNumber { ... }
int signbit(T : MyNumber)(T num) { ... }

// usercode.d
import myNumber;
import std.math;
MyNumber num;
auto x = signbit(num); // tries to call std.math.signbit, and fails


Add sig constraints to:

* signbit
* isFinite.
* isNormal.
* isSubnormal
* sgn.
* nextafter.

https://github.com/dlang/phobos/commit/e4da79f10f52b1a9cae1143c28b8b3b520efaa10
Merge pull request #6040 from quickfur/signbit_sig

Issue 18244: std.math generic functions need to have sig constraints
merged-on-behalf-of: Sebastian Wilzbach 

--


[Issue 18244] Generic functions in std.math cannot be overloaded

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18244

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

   What|Removed |Added

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

--


[Issue 18259] allocatorObject's CAllocatorImpl should store the passed allocator within

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18259

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

https://github.com/dlang/phobos/commit/7220c57286d1742104c058ccdb9ccec34f18a2dc
Fix Issue 18259 - allocatorObject's CAllocatorImpl should store the passed
allocator within

https://github.com/dlang/phobos/commit/382a8ea922d53db5c27e2cd457b79348ed892078
Merge pull request #6044 from edi33416/fix_allocator_obj

Fix Issue 18259 - allocatorObject's CAllocatorImpl should store the passed
allocator within
merged-on-behalf-of: Andrei Alexandrescu 

--


[Issue 18259] allocatorObject's CAllocatorImpl should store the passed allocator within

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18259

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

   What|Removed |Added

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

--


[Issue 17961] std.uni does not compile with -unittest -dip1000

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17961

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||pull

--- Comment #10 from hst...@quickfur.ath.cx ---
Link: https://github.com/dlang/phobos/pull/6041

--


[Issue 17961] std.uni does not compile with -unittest -dip1000

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17961

Carsten Blüggel  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|chi...@posteo.net

--- Comment #9 from Carsten Blüggel  ---
Fixing is under way, see PR #6041

--


[Issue 18259] allocatorObject's CAllocatorImpl should store the passed allocator within

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18259

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
https://github.com/dlang/phobos/pull/6044

--


[Issue 18259] allocatorObject's CAllocatorImpl should store the passed allocator within

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18259

Eduard Staniloiu  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|edi33...@gmail.com

--


[Issue 18259] New: allocatorObject's CAllocatorImpl should store the passed allocator within

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18259

  Issue ID: 18259
   Summary: allocatorObject's CAllocatorImpl should store the
passed allocator within
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: edi33...@gmail.com

allocatorObject uses the passed allocator to allocate the memory chunk that
will store the CAllocatorImpl instance, and thus, the allocator stored within
the newly created instance should be the one that was passed to the function.

This being said, the unittest below should pass.

unittest
{
import std.conv;
import std.experimental.allocator.mallocator;
import std.experimental.allocator.building_blocks.stats_collector;

alias SCAlloc = StatsCollector!(Mallocator, Options.bytesUsed);
SCAlloc statsCollectorAlloc;
assert(statsCollectorAlloc.bytesUsed == 0);

auto _allocator = allocatorObject(statsCollectorAlloc);
// Ensure that the allocator was passed through in CAllocatorImpl
// This allocator was used to allocate the chunk that holds the
// CAllocatorImpl object; which is it's own wrapper
assert(_allocator.impl.bytesUsed == stateSize!(CAllocatorImpl!(SCAlloc)));
_allocator.allocate(1);
assert(_allocator.impl.bytesUsed == stateSize!(CAllocatorImpl!(SCAlloc)) +
1);
}

--


[Issue 17802] allocatorObject doesn't set the passed allocator when it has state into impl field of CAllocatorImpl

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17802

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--


[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18239

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

https://github.com/dlang/phobos/commit/66ede852bf0e76dfdfad7044e475dd147cd0a1e7
Fix Issue 18239: fillWithMemcpy use memset when T.sizeof == 1

https://github.com/dlang/phobos/commit/f760414f76cd0d3fbfd663b44b5b3dbdc3485e45
Merge pull request #6034 from n8sh/fillWithMemcpy-memset

Fix Issue 18239: fillWithMemcpy use memset when T.sizeof == 1

--


[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18239

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

   What|Removed |Added

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

--


[Issue 704] `class` destructor is called even if constructor throws

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=704

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #11 from hst...@quickfur.ath.cx ---
Does this bug only apply for scope classes? I tested the following code on dmd
git master:

--
class MyClass {
this() {
writeln("ctor");
throw new Exception("");
}
~this() {
writeln("dtor");
}
}
void main() {
try {
scope c = new MyClass;
} catch(Exception e) {
// ignore
}
}
--

Only the ctor is called, not the dtor, because the ctor throws and does not
properly construct the object. This is correct behaviour.

However, changing `scope` to `auto` will cause the dtor to still be called, in
spite of the ctor throwing an exception.  According to Andrei's comment, this
is wrong, since the object was not fully initialized, and the exception from
the ctor should be taken to mean that construction of the object has been
abandoned. Not sure if this belongs to this bug, though, or to a different bug,
since the original complaint involved "auto" classes, which I'm assuming was
the original name of scope classes.

--


[Issue 17440] Nullable.nullify() resets referenced object

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17440

--- Comment #16 from hst...@quickfur.ath.cx ---
Rebooted: https://github.com/dlang/phobos/pull/6043

Due to design issues with the current implementation of Nullable, it's not
possible to fix the problem of having two distinct null states without
extensive changes and breaking backward-compatibility.  So for now, we'll just
make it so that .nullify doesn't call .destroy on class references.

--


[Issue 18258] New: std.math.NaN redesign

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18258

  Issue ID: 18258
   Summary: std.math.NaN redesign
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ru...@rumbu.ro

The current signature allows creation only for real NaNs with payloads. It's
impossible to create float or double NaNs with a payload.

Proposal:

Redesign NaN to allow creation of other floating point types:
T NaN(T = real, U)(const U payload) if (isFloatingPoint!T && isUnsigned!U)

--


[Issue 18257] New: std.math.abs/fabs - redesign

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18257

  Issue ID: 18257
   Summary: std.math.abs/fabs - redesign
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ru...@rumbu.ro

Problem 1: std.math.abs signature matches any type which supports the
comparison operator. That means that you cannot write your own abs for a custom
numeric type as long as your type has a comparison operator.

Problem 2: even if a custom numeric type supports comparison operator,
std.math.abs is declared as pure @safe nothrow @nogc, forcing a potential
numeric implementation to decorate his opCmp overload with the same attributes.

Real case: according to IEEE-754/2008, the comparison operator *must* signal an
invalid operation exception if it encounters a NaN value or *must* set a global
error flag. For a standard compliant numeric type, the comparison operator
cannot be decorated with nothrow @nocg (since it's throwing exceptions) and
cannot be pure (since it's setting global error flags).

Proposal 1:
Rethink abs signature to limit usage to standard numeric types, where
comparison is guaranteed to be pure @safe nothrow @nogc

Proposal 2:
Drop fabs. This is probably coming from C where overloads are not available.
There is no need to have two names for a function doing the exact same thing.
abs must catch any signed type, including floating point.

--


[Issue 14998] Cannot put a char into a char[]

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14998

--- Comment #9 from Jack Stouffer  ---
(In reply to Jack Stouffer from comment #8)
> (In reply to Steven Schveighoffer from comment #3)
> > import std.utf;
> > auto r = c.byCodeUnit;
> > r.put('c');
> 
> This actually doesn't work. Making separate issue for it.

Wait, my mistake, the underlying data needs to be char[] not string.

--


[Issue 14998] Cannot put a char into a char[]

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14998

--- Comment #8 from Jack Stouffer  ---
(In reply to Steven Schveighoffer from comment #3)
> import std.utf;
> auto r = c.byCodeUnit;
> r.put('c');

This actually doesn't work. Making separate issue for it.

--


[Issue 18256] Using std.range.put to put a character into a dchar[] segfaults

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18256

Jack Stouffer  changed:

   What|Removed |Added

  Component|installer   |phobos

--


[Issue 18256] Using std.range.put to put a character into a dchar[] segfaults

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18256

Jack Stouffer  changed:

   What|Removed |Added

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

--


[Issue 14998] Cannot put a char into a char[]

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=14998

Jack Stouffer  changed:

   What|Removed |Added

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

--


[Issue 18256] New: Using std.range.put to put a character into a dchar[] segfaults

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18256

  Issue ID: 18256
   Summary: Using std.range.put to put a character into a dchar[]
segfaults
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

import std.stdio;
import std.range;

void main(string[] args)
{
dchar[] a = cast(dchar[]) "aaa"d;
// all three of these segfault
put(a, cast(dchar) 'b');
put(a, cast(wchar) 'b');
put(a, cast(char) 'b');
}

--


[Issue 3345] Static and nonstatic methods with the same name should be allowed

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=3345

Alex  changed:

   What|Removed |Added

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

--


[Issue 6579] Calling static method should *require* using type and not instance, unless specified by author

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=6579

Alex  changed:

   What|Removed |Added

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

--


[Issue 18255] New: std.string.translate takes the output range by value

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18255

  Issue ID: 18255
   Summary: std.string.translate takes the output range by value
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Should be auto ref, and a note should be added to the docs saying that passing
by ref should be the default in user code.

--


[Issue 18254] New: std.range.tee takes the output range by value

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18254

  Issue ID: 18254
   Summary: std.range.tee takes the output range by value
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Should be auto ref, and a note should be added to the docs saying that passing
by ref should be the default in user code.

--


[Issue 18253] New: std.array.replaceInto takes the output range by value

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18253

  Issue ID: 18253
   Summary: std.array.replaceInto takes the output range by value
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Should be auto ref, and a note should be added to the docs saying that passing
by ref should be the default in user code.

--


[Issue 17961] std.uni does not compile with -unittest -dip1000

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17961

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #8 from Martin Nowak  ---
(In reply to Carsten Blüggel from comment #7)
> If there are no objections, I'll file a PR Fix issue 17961 - ...

Yes, those issues prevent trying out dip1000, and it's worthwhile to fix them,
even though support for all of phobos is out of reach for now.
And btw, you shouldn't ask for permission to fix an issue ;).

--


[Issue 18252] New: no property 'tupleof' for type 'string[int]'

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18252

  Issue ID: 18252
   Summary: no property 'tupleof' for type 'string[int]'
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: critical
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: bitwo...@qq.com

Tow arrays of associative array can't be compared.

Compiler: DMD 2.078

Error message:

D:\Dlang\dmd2\windows\bin\..\..\src\druntime\import\object.d(3461,31): Error:
no property 'tupleof' for type 'string[int]'
D:\Dlang\dmd2\windows\bin\..\..\src\druntime\import\object.d(3461,53): Error:
no property 'tupleof' for type 'string[int]'
source\app.d(11,6): Error: template instance object.__equals!(string[int],
string[int]) error instantiating
dmd failed with exit code 1.


=Test code==

import std.stdio;
import std.algorithm;

void main()
{
bool r;

string[int][] aa1;
string[int][] aa2;
// r = __equals!(string[int], string[int])(aa1, aa2); // bug
r = aa1 == aa2; // bug
// r = equal(aa1, aa2); // ok
}

--


[Issue 18247] core.stdc.math functions that never set errno should be pure

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18247

--- Comment #1 from Nathan S.  ---
cos, sin, tan should be removed from list of pure functions. On some platforms
they set errno, on others not. See discussion at
https://github.com/dlang/druntime/pull/2045

--


[Issue 18243] selective import + overload = private visibility

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18243

Seb  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #3 from Seb  ---
I'm re-opening this as its slightly different to 17630 and it's probably
worthwhile to add both tests to the testsuite once this gets fixed.

--


[Issue 18249] pragma decoration skips documentation

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18249

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from Seb  ---
You documented an empty statement.
Pragmas can stand by itself, but they don't have any effect:

https://dlang.org/spec/pragma.html

So what you wanted to do was:

/**
Doc
*/
pragma(inline, true) // <- no semicolon here
void myDocumentedFunction() {}

--


[Issue 5377] Ranges do not support tail-const

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=5377

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--


[Issue 18251] New: deprecate + transition=complex shouldn't look at functions with non-matching if constraints

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18251

  Issue ID: 18251
   Summary: deprecate + transition=complex shouldn't look at
functions with non-matching if constraints
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

---
auto foo(T)(T t)
if (!__traits(isDeprecated, T))
{
return T.init;
}

deprecated
auto foo(T)(T t)
if (__traits(isDeprecated, T))
{
return T.init;
}

deprecated unittest
{
auto b = foo(2 + 2i);
}
---


This shouldn't trigger a deprecation on line 1:

> dmd -unittest -c -o- -transition=complex foo.d

foo.d(1): Deprecation: use of complex type cdouble is deprecated, use
std.complex.Complex!(double) instead
foo.d(8): Deprecation: use of complex type cdouble is deprecated, use
std.complex.Complex!(double) instead

--


[Issue 18250] New: deprecate + transition=complex should check whether the templates are instantiated from a deprecated scope

2018-01-17 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=18250

  Issue ID: 18250
   Summary: deprecate + transition=complex should check whether
the templates are instantiated from a deprecated scope
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

auto foo(T)(T t)
{
return T.init;
}

deprecated unittest
{
auto b = foo(2 + 2i);
}

This shouldn't trigger an error, but it does:

> dmd -unittest -c -o- -transition=complex foo.d


foo.d(1): Deprecation: use of complex type cdouble is deprecated, use
std.complex.Complex!(double) instead
foo.d(3): Deprecation: use of complex type cdouble is deprecated, use
std.complex.Complex!(double) instead
foo.d(1): Deprecation: use of complex type cdouble is deprecated, use
std.complex.Complex!(double) instead

--