[Issue 15812] static struct inside extern(C++) class cannot be used as key to associative array

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15812

Dlang Bot  changed:

   What|Removed |Added

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

--- Comment #4 from Dlang Bot  ---
dlang/dmd pull request #10782 "fix Issue 15812 - static struct inside
extern(C++) class cannot be us…" was merged into master:

- 143f827c04b2d9ce1e3969bb267f0173a635d17c by Walter Bright:
  fix Issue 15812 - static struct inside extern(C++) class cannot be used as
key to associative array

https://github.com/dlang/dmd/pull/10782

--


[Issue 15812] static struct inside extern(C++) class cannot be used as key to associative array

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15812

Dlang Bot  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #3 from Dlang Bot  ---
@WalterBright created dlang/dmd pull request #10782 "fix Issue 15812 - static
struct inside extern(C++) class cannot be us…" fixing this issue:

- fix Issue 15812 - static struct inside extern(C++) class cannot be used as
key to associative array

https://github.com/dlang/dmd/pull/10782

--


[Issue 15812] static struct inside extern(C++) class cannot be used as key to associative array

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15812

--- Comment #2 from Walter Bright  ---
It will work if toHash() is declared as extern (D).

--


[Issue 13009] [REG2.064] inout overload conflicts with non-inout when used via alias this

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13009

--- Comment #25 from Vladimir Panteleev  ---
(In reply to Walter Bright from comment #24)
> If you can get a test case without imports that is complete, that would be
> appreciated.

/ test.d /
struct RefCounted(T)
{
ref T refCountedPayload()
{
assert(false);
}

ref inout(T) refCountedPayload() inout 
{
assert(false);
}

alias refCountedPayload this;
}

struct S
{
struct Payload
{
int[] data;
}

RefCounted!Payload payload;
alias X = typeof(payload.data[0]);

void foo()
{
payload.data[0] = 0;
}
}

int main(string[] argv)
{
return 0;
}
//

It looks like the problem is specific to typeof this time.

--


[Issue 15459] [REG2.065.0] stdin.byLine.each!(map!somefunc) compiles, fails to link with ld

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15459

--- Comment #13 from Walter Bright  ---
The Comment 6 example still fails to compile. It looks like the speculative
compilation in the `is(typeof(map))` wound up hiding the error in somefunc().

--


[Issue 13009] [REG2.064] inout overload conflicts with non-inout when used via alias this

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=13009

--- Comment #24 from Walter Bright  ---
If you can get a test case without imports that is complete, that would be
appreciated.

--


[Issue 12420] [AA] Can't set associative array with array as key value using key type

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=12420

--- Comment #16 from Dlang Bot  ---
@WalterBright updated dlang/dmd pull request #4835 "[REG] fix Issue 12420 -
[AA] Can't set associative array with array as key …" fixing this issue:

- fix Issue 12420 - [AA] Can't set associative array with array as key value
using key type

https://github.com/dlang/dmd/pull/4835

--


[Issue 20576] TemplateTypeParameter and TemplateValueParameter default values are not checked

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20576

Basile-z  changed:

   What|Removed |Added

   Severity|normal  |minor

--- Comment #3 from Basile-z  ---
I agree about the waste of time but keep the issue opened, just to be clear on
the fact that the problem is already known.

--


[Issue 20576] TemplateTypeParameter and TemplateValueParameter default values are not checked

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20576

Mathias LANG  changed:

   What|Removed |Added

 CC||pro.mathias.l...@gmail.com

--- Comment #2 from Mathias LANG  ---
I'm not sure that's an issue.

In trivial cases like this the code is obviously wrong, but the only way we're
going to realistically catch all these is by always instantiating the template
with default parameters, which is 1) not always possible, 2) a waste of
compilation time.

--


[Issue 20576] TemplateTypeParameter and TemplateValueParameter default values are not checked

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20576

Basile-z  changed:

   What|Removed |Added

Summary|TemplateTypeParameter   |TemplateTypeParameter and
   |default values are not  |TemplateValueParameter
   |checked |default values are not
   ||checked

--


[Issue 20576] TemplateTypeParameter default values are not checked

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20576

--- Comment #1 from Basile-z  ---
TemplateValueParameter too:

---
void foo(ubyte u = 0xFF1)()
{
}

void main()
{
foo!1();
}
---

--


[Issue 20576] New: TemplateTypeParameter default values are not checked

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20576

  Issue ID: 20576
   Summary: TemplateTypeParameter default values are not checked
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: accepts-invalid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

The following code should not compile

---
void foo(T : Object = INVALID)(T t)
{

}

void main()
{
foo(null);
}
---

because INVALID does not give a valid symbol, although it is not used in the
call.

--


[Issue 15851] Access violation when foreaching variadic template argument tuple

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15851

moonlightsenti...@disroot.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||moonlightsentinel@disroot.o
   ||rg
 Resolution|--- |FIXED

--- Comment #1 from moonlightsenti...@disroot.org ---
This no longer compiles:

onlineapp.d(14): Error: switch skips declaration of variable
onlineapp.walkArgumentTuple!(Foo).walkArgumentTuple.thing at onlineapp.d(16)

--


[Issue 20575] New: Version'ed cases in

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20575

  Issue ID: 20575
   Summary: Version'ed cases in
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: moonlightsenti...@disroot.org

Consider the following example:

void main()
{
import std.stdio;

foreach (i; 1 .. 4)
{
write(i, ": ");
switch (i)
{
version (A) case 1:
version (B) case 2:
write("Case");
break;

case 3:

default:
write("Default");
}
writeln();
}
}

Executing this example with different versions yields strange results:

[ ]: // OK
1: Default
2: Default
3: Default

[A]: // Strange
1:
2: Default
3: Default

[B]: // Maybe?
1: Default
2: Default
3: Default

[A, B]: // OK
1: Case
2: Case
3: Default

[B] suggests that the missing A discards both case statements (which form a
CaseRangeStatement) and hence executes the default.

But [A] seems to discard "case 2: writeln(...);" without implicit fallthough /
compiler warning.

--


[Issue 20575] Strange behaviour of version'ed switch cases

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20575

moonlightsenti...@disroot.org changed:

   What|Removed |Added

Summary|Version'ed cases in |Strange behaviour of
   ||version'ed switch cases

--


[Issue 20574] New: Ambigious parameter names should trigger an error

2020-02-11 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=20574

  Issue ID: 20574
   Summary: Ambigious parameter names should trigger an error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: purema...@zoadian.de


import std.stdio;
import std.traits;

void foo(int b);
void foo(int a);

void foo(int a) {
writeln(a);
}

pragma(msg, ParameterIdentifierTuple!foo); // prints "b"

void main() {
foo(5);
}
```

Ambigious parameter names should trigger an error, as per spec they _are_ part
of the public API.
Also if you imagine foo beeing declared in two seperate modules i suspect
import oder would change the behaviour of ParameterIdentifierTuple.
If D gets named parameters this will probably also matter.

--