[Issue 18493] [betterC] Can't use aggregated type with postblit

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Radu Racariu  ---
Declaring `C` as 

---
struct C
{
S s1;
}
---

makes the test case compile.

--

[Issue 18419] make all Phobos unittests version(StdUnittest)

[d-bugmail--- via Digitalmars-d-bugs]

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

Nathan S.  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan S.  ---
Idea nixed, so issue should be closed.

--

[Issue 18768] object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2166

--

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/druntime/pull/2166

--

[Issue 18768] New: object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18768
   Summary: object.getArrayHash with custom toHash shouldn't just
sum hashes of array elements
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Currently:
```
if(!hasCustomToHash(element))
return hashOf(ptr[0 .. elementSize * count], 0);

size_t hash = 0;
foreach(size_t i; 0 .. count)
hash += element.getHash(ptr + i * elementSize);
return hash;
```

--

[Issue 18767] New: __xtoHash memberwise hashing shouldn't just sum the member hashes

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18767
   Summary: __xtoHash memberwise hashing shouldn't just sum the
member hashes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Currently:
```
const(char)* code =
"size_t h = 0;" ~
"foreach (i, T; typeof(p.tupleof))" ~
"h += typeid(T).getHash(cast(const void*)[i]);" ~
"return h;";
```

--

[Issue 18766] std.typecons.Tuple.toHash could be improved

[d-bugmail--- via Digitalmars-d-bugs]

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

Nathan S.  changed:

   What|Removed |Added

   Severity|minor   |enhancement

--

[Issue 18766] std.typecons.Tuple.toHash could be improved

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #1 from Nathan S.  ---
Pull request: https://github.com/dlang/phobos/pull/6457

--

[Issue 18766] New: std.typecons.Tuple.toHash could be improved

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18766
   Summary: std.typecons.Tuple.toHash could be improved
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Current std.typecons.Tuple has a custom `toHash` that is just the sum of the
hashes of the tuple's fields.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #8 from Andrei Alexandrescu  ---
The problem is that static methods don't call the static invariant.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #7 from Walter Bright  ---
A `static invariant` does not have special semantics distinct from `invariant`
other than it does not have a `this` parameter. That fully explains the
observed behavior. The `static` is not ignored:

  struct S {
int i;
static invariant { assert (i == 3); } // Error: need this for i of type int
void foo() {}
  }

  void main() {
S s;
s.foo(); // invariant does get called
  }

Whether that is desirable behavior or not is another matter entirely. Our
general practice when confronted with these sorts of issues is to make it an
error until we figure out what is the best approach, if there even is one,
rather than inventing arbitrary behavior without much of any supporting
rationale or use cases.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #6 from FeepingCreature  ---
In my opinion, static this sets the precedent that static + class-level feature
= module-level feature.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #5 from Jonathan M Davis  ---
(In reply to FeepingCreature from comment #2)
> In case 1, I maintain that this is a bug - the compiler should not
> smile-and-nod while silently ignoring syntax that hints at a semantic that
> does not apply.

The reality of the matter is that the compiler ignores attributes like statict
all over the place (e.g. static on most things at module scope is allowed and
ignored, and you can do something like put @safe on a member variable without
complaint from the compiler). If anything, it's extremely typical for the
compiler to ignore attributes that don't apply rather than to treat them as an
error. In some ways, this can be annoying, but it does help avoid problems in
generic code. So, whether an error should be given in this particular case and
not others is up for debate, but it's par for the course around here.

(In reply to RazvanN from comment #4)
> What about object that have static fields? If you have a static function
> which modify static fields? I would argue that an invariant might want to
> check whether a static function has modified the state of the object.

We could certainly add a feature like that, but it's certainly not what
invariant was designed for. Its purpose was specifically to verify the state of
an object, and arguably, the static fields of an object aren't any different
from those at module-sope except for the fact that they're scoped to be inside
a struct or class. And as such, having an invariant for them would be pretty
weird and is of pretty debatable value. If we went down that route, the
question would become why we don't have module-level invariants.

--

[Issue 18719] Doubly-called constructor against member when using forwarding constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 18719] Doubly-called constructor against member when using forwarding constructors

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/cbb49cb2591bd5aa3e5f9e0b8a4350cb04ec1206
Fix Issue 18719 - Doubly-called constructor against member when using
forwarding constructors

https://github.com/dlang/dmd/commit/ebecaf95ec84018c36cd1c388c4d9102c23622f7
Merge pull request #8167 from RazvanN7/Issue_18719

Fix Issue 18719 - Doubly-called constructor against member when using
forwarding constructors
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 18762] DMD should use a unique path/filename for __stdin.o

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/fdc6353140f059c25218a4d057eb7ebe20d69ef2
Fix Issue 18762 - DMD should use a unique path/filename for __stdin.o

https://github.com/dlang/dmd/commit/bfb89f5099f4607d2b56a0508b3bbc6cec800de3
Merge pull request #8174 from CyberShadow/pull-20180416-133742

Fix Issue 18762 - DMD should use a unique path/filename for __stdin.o
merged-on-behalf-of: Andrei Alexandrescu <andra...@users.noreply.github.com>

--

[Issue 18762] DMD should use a unique path/filename for __stdin.o

[d-bugmail--- via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from RazvanN  ---
(In reply to uplink.coder from comment #3)
> Well invariants cannot apply to static methods since they are only concerned
> about the object's state.
> which by definition cannot be directly touched in static functions.
> that's why it's not called.
> 
> I don't see that there is a basis to issue a warning.

What about object that have static fields? If you have a static function which
modify static fields? I would argue that an invariant might want to check
whether a static function has modified the state of the object.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 CC||uplink.co...@googlemail.com

--- Comment #3 from uplink.co...@googlemail.com ---
Well invariants cannot apply to static methods since they are only concerned
about the object's state.
which by definition cannot be directly touched in static functions.
that's why it's not called.

I don't see that there is a basis to issue a warning.

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from FeepingCreature  ---
In case 1, I maintain that this is a bug - the compiler should not
smile-and-nod while silently ignoring syntax that hints at a semantic that does
not apply.

--

[Issue 18762] DMD should use a unique path/filename for __stdin.o

[d-bugmail--- via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

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

--

[Issue 18757] static invariant{} should either work or not be valid syntax

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
(In reply to FeepingCreature from comment #0)
> Right now, you can define a struct to have a static invariant:
> 
> struct S {
>   static invariant { assert(false); }
>   static void foo() { }
> }
> 
> But the invariant will not be checked when calling foo.
> 
> Either this should work, or "static invariant {}" should be a syntax error.

Placing static in front of an invariant has no effect on the invariant. The
problem with the above code is that the method foo is marked as static:

struct S
{
invariant { (assert (false); }
static void foo() {}
}

void main()
{
S s;
s.foo(); \\ invariant does not get called
}

while :

struct S
{
static invariant { (assert (false); }
void foo() {}
}

void main()
{
S s;
s.foo(); \\ invariant does get called
}

So we can conclude that invariants are not called for static functions. The
spec does not mention anything about this so there are 2 possibilities :

1. Invariants were designed only for struct/class instances (in which case the
bug report will be closed with a spec update)

2. Invariants should also be called when static methods are called (in which
case this should be fixed)

--

[Issue 18736] constructor calls allowed after case labels

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/15f525620895727147cf12e33596ae1a2d3ffa45
fix Issue 18736 - constructor calls allowed after case labels

https://github.com/dlang/dmd/commit/49268c71adbc6631013d32c70152fd665d70760c
Merge pull request #8143 from WalterBright/fix18736

fix Issue 18736 - constructor calls allowed after case labels

--

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #10 from Mike Franklin  ---
PR 8173 seems to take care of the case...

module betterc;
enum b = typeid(size_t) is typeid(uint)

... but still fails for ...

import std.format;
import std.stdio;
void main()
{
enum s = "%1$s,%2$s".format("foo","bar");
writeln(s);
}

... with the same TypeInfo error.

However, if I comment out the TypeInfo check altogether, the `format` test case
fails with...

phobos/std/range/primitives.d(405): Error: static assert:  "Cannot put a
const(char)[] into a Appender!string."
phobos/std/format.d(1184):instantiated from here: put!(Appender!string,
const(char)[])
/phobos/std/format.d(473):instantiated from here:
writeUpToNextSpec!(Appender!string)
phobos/std/format.d(6168):instantiated from here:
formattedWrite!(Appender!string, char, string, string)
main.d(5):instantiated from here: format!(char, string, string)

I'm wondering if there was another change to Phobos around the same time frame
was the TypeInfo change that prevents the `format` expression from evaluating
at compile-time.

--

[Issue 18756] Escaping address of temporary struct field

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Jonathan M Davis  ---
(In reply to anonymous4 from comment #3)
> (In reply to Jonathan M Davis from comment #2)
> > because it's always a bug.
> It's correct when the result is passed to a function parameter.

How so?

--

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #9 from Mike Franklin  ---
Working on a fix at https://github.com/dlang/dmd/pull/8173

--

[Issue 18756] Escaping address of temporary struct field

[d-bugmail--- via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--- Comment #3 from anonymous4  ---
(In reply to Jonathan M Davis from comment #2)
> because it's always a bug.
It's correct when the result is passed to a function parameter.

--

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #8 from Mike Franklin  ---
(In reply to Rainer Schuetze from comment #7)
> I think the main issue is that the compiler does not distinguish between
> information needed at compile time and what's necessary inside the object
> file.

Ok, I understand now:  `enum b = typeid(size_t) is typeid(uint);` should be
evaluated at compile time, and I the -betterC limitations should only apply at
runtime.

--