On 1/25/18 8:24 AM, Mike Parker wrote:
On Thursday, 25 January 2018 at 12:58:12 UTC, Jonathan M Davis wrote:
Thinking about it, I do vaguely recall a discussion sometime last year
about an invariant being invisibly inserted under some set of
circumstances. Maybe that's what's happening? I beli
On Thursday, 25 January 2018 at 12:58:12 UTC, Jonathan M Davis
wrote:
Thinking about it, I do vaguely recall a discussion sometime
last year about an invariant being invisibly inserted under
some set of circumstances. Maybe that's what's happening? I
believe that it was complained about in th
On Thursday, January 25, 2018 12:42:57 Kagamin via Digitalmars-d-learn
wrote:
> See https://ideone.com/VZ97dh
I don't know what's going on there. Such an assertion does not seem in line
with what Walter has typically said on the subject.
Thinking about it, I do vaguely recall a discussion someti
See https://ideone.com/VZ97dh
On Thursday, January 25, 2018 12:38:25 Kagamin via Digitalmars-d-learn
wrote:
> On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis
>
> wrote:
> > Actually, assert on a pointer to a struct or a reference to a
> > class checks for null _and_ calls the invariant, and that
> > hasn't chang
On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis
wrote:
Actually, assert on a pointer to a struct or a reference to a
class checks for null _and_ calls the invariant, and that
hasn't changed. But you have to actually assert the pointer or
reference if you want to do that, and the
On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis
wrote:
On Thursday, January 25, 2018 10:17:34 Kagamin via
Digitalmars-d-learn wrote:
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
wrote:
> (so there's no need to dereference the pointer to call it)
It used to che
On Thursday, 25 January 2018 at 10:17:34 UTC, Kagamin wrote:
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
wrote:
(so there's no need to dereference the pointer to call it)
It used to check this pointer with an assert. When did it
change?
Fortunately, I have some compilers
On Thursday, January 25, 2018 10:17:34 Kagamin via Digitalmars-d-learn
wrote:
> On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
>
> wrote:
> > (so there's no need to dereference the pointer to call it)
>
> It used to check this pointer with an assert. When did it change?
Actually,
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
wrote:
(so there's no need to dereference the pointer to call it)
It used to check this pointer with an assert. When did it change?
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
wrote:
On Wednesday, January 24, 2018 01:48:45 Alex via
Digitalmars-d-learn wrote:
the story of
https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org continues
How can this be?
void main()
{
auto s = S();
On Wednesday, January 24, 2018 01:48:45 Alex via Digitalmars-d-learn wrote:
> the story of
> https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org
> continues
>
> How can this be?
>
> void main()
> {
> auto s = S();
> auto t = T!s();
> assert(typeof(t).dummy == null);
>
On Wednesday, 24 January 2018 at 01:48:45 UTC, Alex wrote:
Ah... I figured it out.
For using the function of S, an object does not have to exist...
And in case I would return a member from S, there is a
segmentation violation, as expected.
So, everything is ok.
Sorry for noise.
the story of
https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org
continues
How can this be?
void main()
{
auto s = S();
auto t = T!s();
assert(typeof(t).dummy == null);
assert(t.dummy == null);
t.foo;
}
struct S
{
auto fun()
{
return 42;
14 matches
Mail list logo