Re: getting member functions of a struct and Error: identifier expected following ., not this

[thedeemon via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 00:00:38 UTC, aliak wrote:
Hi, I'm trying to get a list of only member functions of a 
struct. I've found that if you do not declare a struct as 
static inside a scope, then there's a hidden "this" member as 
part of the struct. Can someone explain the logic there?


The struct defined inside a scope can mention variables defined 
in that scope (e.g. use them in its methods), so it needs a 
pointer to the place where those closed variables live. That's 
the main difference between such struct and a static one that 
cannot use those scope vars. I guess you're seeing that pointer 
as additional member.



As for static foreach, when you write a simple foreach over some 
compile-time tuple (like in this case), it's unrolled at compile 
time similarly to "static foreach", the main difference is 
whether it creates a sub-scope for the loop body or not. 
"foreach" creates one, "static foreach" doesn't.

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[drug via Digitalmars-d]

24.01.2018 10:25, Jonathan M Davis пишет:


If you need to interact with time_t, there's SysTime.toUnixTime,
SysTime.fromUnixTime, stdTimeToUnixTime, and unixTimeToStdTime - assuming of
course that time_t is unix time. But if it's not, you're kind of screwed in
general with regards to interacting with anything else, since time_t is
technically opaque. It's just _usually_ unix time and most stuff is going to
assume that it is. There's also SysTime.toTM, though tm isn't exactly a fun
data type to deal with if you're looking to convert anything.

But if you care about calendar stuff, using January 1st, 1 A.D. as your
epoch is far cleaner than an arbitrary date like January 1st, 1970. My guess
is that that epoch was originally selected to try and keep the values small
in a time where every bit mattered. It's not a particularly good choice
otherwise, but we've been stuck dealing with it ever since, because that's
what C and C++ continue to use and what OS APIs typically use.

- Jonathan M Davis




I'm agree with you that 1 A.D. is better epoch than 1970. IIRC c++11 by 
default uses 1 nsec presicion so even 64 bits are not enough to present 
datetime from January 1st, 1 A.D. to our days.


And by the way I'd like to thank you for your great work - in comparison 
to very (at least for me) inconsistent means c/c++ provide to handle 
date and time, std.datetime is the great pleasure to work with.

Re: The most confusing error message

[Petar via Digitalmars-d]

On Wednesday, 24 January 2018 at 07:32:17 UTC, Petar Kirov 
[ZombineDev] wrote:
On Wednesday, 24 January 2018 at 07:21:09 UTC, Shachar Shemesh 
wrote:

test.d(6): Error: struct test.A(int var = 3) is used as a type

Of course it is. That's how structs are used.

Program causing this:
struct A(int var = 3) {
int a;
}

void main() {
A a;
}

To resolve, you need to change A into A!(). For some reason I 
have not been able to fathom, default template parameters on 
structs don't work like they do on functions.


Because IFTI is short for implicit function


(Heh, the Send button is too easy to press on the mobile version 
of the forum.)


Because IFTI is short for implicit function template 
instantiation. We don't have this feature for any other type of 
template, though IIRC it has been discussed before. Though one 
may argue that we have this feature for mixin templates:


https://dlang.org/spec/template-mixin.html
If the TemplateDeclaration has no parameters, the mixin form that 
has no !(TemplateArgumentList) can be used.

Re: The most confusing error message

[Petar via Digitalmars-d]

On Wednesday, 24 January 2018 at 07:21:09 UTC, Shachar Shemesh 
wrote:

test.d(6): Error: struct test.A(int var = 3) is used as a type

Of course it is. That's how structs are used.

Program causing this:
struct A(int var = 3) {
int a;
}

void main() {
A a;
}

To resolve, you need to change A into A!(). For some reason I 
have not been able to fathom, default template parameters on 
structs don't work like they do on functions.


Because IFTI is short for implicit function

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[Jonathan M Davis via Digitalmars-d]

On Wednesday, January 24, 2018 10:05:12 drug via Digitalmars-d wrote:
> 24.01.2018 03:15, Jonathan M Davis пишет:
> > On Tuesday, January 23, 2018 23:27:27 Nathan S. via Digitalmars-d wrote:
> >> https://dlang.org/phobos/std_datetime_systime.html#.Clock.currStdTime
> >> """
> >> @property @trusted long currStdTime(ClockType clockType =
> >> ClockType.normal)();
> >> Returns the number of hnsecs since midnight, January 1st, 1 A.D.
> >> for the current time.
> >> """
> >>
> >> This choice of offset seems Esperanto-like: deliberately chosen
> >> to equally inconvenience every user. Is there any advantage to
> >> this at all on any platform, or is it just pure badness?
> >
> > Your typical user would use Clock.currTime and get a SysTime. The badly
> > named "std time" is the internal representation used by SysTime. Being
> > able to get at it to convert to other time representations can be
> > useful, but most code doesn't need to do anything with it.
> >
> > "std time" is from January 1st 1 A.D. because that's the perfect
> > representation for implementing ISO 8601, which is the standard that
> > std.datetime follows, implementing the proleptic Gregorian calendar
> > (i.e. it assumes that the calendar was always the Gregorian calendar
> > and doesn't do anything with the Julian calendar).
> >
> > https://en.wikipedia.org/wiki/ISO_8601
> > https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar
> >
> > The math is greatly simplified by using January 1st 1 A.D. as the start
> > date and by assuming Gregorian for the whole way.
> >
> > C# does the same thing with its date/time stuff - it even uses
> > hecto-nanoseconds exactly like we do. hnsecs gives you the optimal
> > balance between precision and range that can be gotten with 64 bits (it
> > covers from about 22,000 B.C. to about 22,000 A.D., whereas IIRC, going
> > one decimal place more precise would reduce it to about 200 years in
> > either direction).
> >
> > - Jonathan M Davis
>
> I guess he meant it's inconvenient working with c/c++ for example to
> add/subtract difference between epoch in c/c++ and d

If you need to interact with time_t, there's SysTime.toUnixTime,
SysTime.fromUnixTime, stdTimeToUnixTime, and unixTimeToStdTime - assuming of
course that time_t is unix time. But if it's not, you're kind of screwed in
general with regards to interacting with anything else, since time_t is
technically opaque. It's just _usually_ unix time and most stuff is going to
assume that it is. There's also SysTime.toTM, though tm isn't exactly a fun
data type to deal with if you're looking to convert anything.

But if you care about calendar stuff, using January 1st, 1 A.D. as your
epoch is far cleaner than an arbitrary date like January 1st, 1970. My guess
is that that epoch was originally selected to try and keep the values small
in a time where every bit mattered. It's not a particularly good choice
otherwise, but we've been stuck dealing with it ever since, because that's
what C and C++ continue to use and what OS APIs typically use.

- Jonathan M Davis

The most confusing error message

[Shachar Shemesh via Digitalmars-d]

test.d(6): Error: struct test.A(int var = 3) is used as a type

Of course it is. That's how structs are used.

Program causing this:
struct A(int var = 3) {
int a;
}

void main() {
A a;
}

To resolve, you need to change A into A!(). For some reason I have not 
been able to fathom, default template parameters on structs don't work 
like they do on functions.

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[drug via Digitalmars-d]

24.01.2018 03:15, Jonathan M Davis пишет:

On Tuesday, January 23, 2018 23:27:27 Nathan S. via Digitalmars-d wrote:

https://dlang.org/phobos/std_datetime_systime.html#.Clock.currStdTime
"""
@property @trusted long currStdTime(ClockType clockType =
ClockType.normal)();
Returns the number of hnsecs since midnight, January 1st, 1 A.D.
for the current time.
"""

This choice of offset seems Esperanto-like: deliberately chosen
to equally inconvenience every user. Is there any advantage to
this at all on any platform, or is it just pure badness?


Your typical user would use Clock.currTime and get a SysTime. The badly
named "std time" is the internal representation used by SysTime. Being able
to get at it to convert to other time representations can be useful, but
most code doesn't need to do anything with it.

"std time" is from January 1st 1 A.D. because that's the perfect
representation for implementing ISO 8601, which is the standard that
std.datetime follows, implementing the proleptic Gregorian calendar (i.e. it
assumes that the calendar was always the Gregorian calendar and doesn't do
anything with the Julian calendar).

https://en.wikipedia.org/wiki/ISO_8601
https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

The math is greatly simplified by using January 1st 1 A.D. as the start date
and by assuming Gregorian for the whole way.

C# does the same thing with its date/time stuff - it even uses
hecto-nanoseconds exactly like we do. hnsecs gives you the optimal balance
between precision and range that can be gotten with 64 bits (it covers from
about 22,000 B.C. to about 22,000 A.D., whereas IIRC, going one decimal
place more precise would reduce it to about 200 years in either direction).

- Jonathan M Davis



I guess he meant it's inconvenient working with c/c++ for example to 
add/subtract difference between epoch in c/c++ and d

Re: Shouldn't invalid references like this fail at compile time?

[Mike Franklin via Digitalmars-d]

On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote:

Well if your embedded device has all that on it you should be 
sitting on an OS with proper memory management support.


I don't see how the OS can help if the underlying hardware 
doesn't have an MMU.  That being said, admittedly, the more 
capable microcontrollers do have an MPU that can be configured to 
throw a hardware exception.



We don't use D, it is all C++ and some Ada in the older systems.


Why don't you use D?

Mike

Re: Shouldn't invalid references like this fail at compile time?

[lobo via Digitalmars-d]

On Wednesday, 24 January 2018 at 02:28:12 UTC, Mike Franklin 
wrote:
On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright 
wrote:


Microcontroller code tends to be small and so it's unlikely 
that you'll need to worry about it.


I think you need to get involved in programming 
microcontrollers again because the landscape has changed 
drastically.  The microcontrollers I use now are more powerful 
than PCs of the 90's.


The project I'm currently working on is an HMI for industrial 
control with a full touchscreen 2D GUI.  The code base  is 
240,084 lines of code and that doesn't even include the 3rd 
party libraries I'm using (e.g. 2D graphics library, newlib C 
library, FreeType font rendering library).  That's not "small" 
by my standard of measure.


And with devices such as this being increasingly connected to 
the Internet, such carelessness can easily be exploited as 
evident in https://en.wikipedia.org/wiki/2016_Dyn_cyberattack   
And that's not to mention the types of critical systems that 
run on such platforms that we are increasingly becoming more 
dependent on.


We better start worrying about it.

Mike


Well if your embedded device has all that on it you should be 
sitting on an OS with proper memory management support. Even the 
hokey FreeRTOS can be configured to throw a hardware exception on 
nullptr access.


I work on critical systems SW developing life support and pace 
makers. For us nullptrs and memory management is not an issue. It 
is not hard to design these problems out of the critical 
component architecture.


The bigger problem is code logic bugs and for that we make heavy 
use of asserts and in-out contracts. We don't use D, it is all 
C++ and some Ada in the older systems.


bye,
lobo

Re: Shouldn't invalid references like this fail at compile time?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, January 24, 2018 02:28:12 Mike Franklin via Digitalmars-d 
wrote:
> On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright
>
> wrote:
> > Microcontroller code tends to be small and so it's unlikely
> > that you'll need to worry about it.
>
> I think you need to get involved in programming microcontrollers
> again because the landscape has changed drastically.  The
> microcontrollers I use now are more powerful than PCs of the 90's.
>
> The project I'm currently working on is an HMI for industrial
> control with a full touchscreen 2D GUI.  The code base  is
> 240,084 lines of code and that doesn't even include the 3rd party
> libraries I'm using (e.g. 2D graphics library, newlib C library,
> FreeType font rendering library).  That's not "small" by my
> standard of measure.
>
> And with devices such as this being increasingly connected to the
> Internet, such carelessness can easily be exploited as evident in
> https://en.wikipedia.org/wiki/2016_Dyn_cyberattack   And that's
> not to mention the types of critical systems that run on such
> platforms that we are increasingly becoming more dependent on.
>
> We better start worrying about it.

Well, we can just mandate that dereferencing null be @safe such that if it's
not guaranteed that dereferencing null will segfault, the compiler will have
to insert additional checks. We need to do that anyway for the overly large
objects (and unfortunately don't last I heard). But as long as null checks
aren't inserted when the target is going to segfault on dereferencing null,
then we're not inserting unnecessary checks. That way, stuff running on a
normal CPU would be the same as now (save for the objects that are too large
for segfaulting to work), and targets like a microcontroller would get the
extra checks so that they behaved more like if they were going to segfault
on dereferencing null.

But making dereferencing null @system makes no sense, because that would
mean that dereferencing pointers and references in general could not be
@safe. So, basically, anything that's not on the stack would then be
@system. And that would destroy @safe.

- Jonathan M Davis

Re: Shouldn't invalid references like this fail at compile time?

[Mike Franklin via Digitalmars-d]

On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright 
wrote:


Microcontroller code tends to be small and so it's unlikely 
that you'll need to worry about it.


I think you need to get involved in programming microcontrollers 
again because the landscape has changed drastically.  The 
microcontrollers I use now are more powerful than PCs of the 90's.


The project I'm currently working on is an HMI for industrial 
control with a full touchscreen 2D GUI.  The code base  is 
240,084 lines of code and that doesn't even include the 3rd party 
libraries I'm using (e.g. 2D graphics library, newlib C library, 
FreeType font rendering library).  That's not "small" by my 
standard of measure.


And with devices such as this being increasingly connected to the 
Internet, such carelessness can easily be exploited as evident in 
https://en.wikipedia.org/wiki/2016_Dyn_cyberattack   And that's 
not to mention the types of critical systems that run on such 
platforms that we are increasingly becoming more dependent on.


We better start worrying about it.

Mike

Re: static weirdness

[Alex via Digitalmars-d-learn]

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();
 auto t = T!s();
 assert(typeof(t).dummy == null);
 assert(t.dummy == null);
 t.foo;

}

struct S
{
 auto fun()
 {
  return 42;
 }
}

struct T(alias stats)
{
 static typeof(stats)* dummy; // line 21
 static auto foo()
 {
  assert(dummy == null); // line 24
 assert(dummy.fun == 42); //line 25
 }
}

I thought, if I don't initialize a pointer, like the one in 
line

21 (I assert this by the check in line 24) I can't use it line
line 25.
However, I can...


That has nothing to do with static. That has to do with the 
fact that S.fun
is non-virtual (so there's no need to dereference the pointer 
to call it),
and fun doesn't access any members, so it doesn't need to 
dereference the
this pointer internally either. And since the pointer is never 
dereferenced,

it doesn't matter that it's null.


That's cool, by the way :)


You'd get the same behavior if you used
a non-static S.

On a side note, if you're checking for null, it's better to use 
the is operator rather than ==. For strings, there's a semantic 
difference, so it really matters. For classes, it avoids 
calling the free function opEquals (which will give the same 
result, but it's a pointless function call when you could just 
use is and avoid the call). For pointers, it matters that much 
less, but since it does matter in the other cases (especially 
strings), it's a good habit to get into just using is null 
instead of == null.



Thanks.

Re: static weirdness

[Jonathan M Davis via Digitalmars-d-learn]

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);
>  assert(t.dummy == null);
>  t.foo;
>
> }
>
> struct S
> {
>  auto fun()
>  {
>   return 42;
>  }
> }
>
> struct T(alias stats)
> {
>  static typeof(stats)* dummy; // line 21
>  static auto foo()
>  {
>   assert(dummy == null); // line 24
>  assert(dummy.fun == 42); //line 25
>  }
> }
>
> I thought, if I don't initialize a pointer, like the one in line
> 21 (I assert this by the check in line 24) I can't use it line
> line 25.
> However, I can...

That has nothing to do with static. That has to do with the fact that S.fun
is non-virtual (so there's no need to dereference the pointer to call it),
and fun doesn't access any members, so it doesn't need to dereference the
this pointer internally either. And since the pointer is never dereferenced,
it doesn't matter that it's null. You'd get the same behavior if you used
a non-static S.

On a side note, if you're checking for null, it's better to use the is
operator rather than ==. For strings, there's a semantic difference, so it
really matters. For classes, it avoids calling the free function opEquals
(which will give the same result, but it's a pointless function call when
you could just use is and avoid the call). For pointers, it matters that
much less, but since it does matter in the other cases (especially strings),
it's a good habit to get into just using is null instead of == null.

- Jonathan M Davis

Re: static weirdness

[Alex via Digitalmars-d-learn]

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.

static weirdness

[Alex via Digitalmars-d-learn]

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;
}
}

struct T(alias stats)
{
static typeof(stats)* dummy; // line 21
static auto foo()
{
assert(dummy == null); // line 24
assert(dummy.fun == 42); //line 25
}
}

I thought, if I don't initialize a pointer, like the one in line 
21 (I assert this by the check in line 24) I can't use it line 
line 25.

However, I can...

Re: Shouldn't invalid references like this fail at compile time?

[Walter Bright via Digitalmars-d]

On 1/23/2018 4:42 PM, Mike Franklin wrote:
That's what kindof ticks me off about this "null is memory safe" argument; it 
seems to be only applicable to a specific platform and environment.


It's an extremely useful argument, though, as modern computers have virtual 
memory systems that map 0 to a seg fault, and have since the 80's, specifically 
because it DOES catch lots and lots of bugs.


I always thought the IBM PC should have put the ROMs at address 0 instead of 
0. It probably would have saved billions of dollars.



I have a micocontroller in front of me where an address of null (essentially 0) is a 
perfectly valid memory address.


Microcontroller code tends to be small and so it's unlikely that you'll need to 
worry about it.

[Issue 18289] static function and access frame

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

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||slavo5...@yahoo.com

--

Re: Shouldn't invalid references like this fail at compile time?

[Mike Franklin via Digitalmars-d]

On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer 
wrote:


[1] Note: the reason they are safe is because they generally 
result in a segfault, which doesn't harm any memory. This is 
very much a user-space POV, and doesn't take into account 
kernel-space where null dereferences may actually be valid 
memory! It also doesn't (currently) take into account possible 
huge objects that could extend into valid memory space, even in 
user space.


That's what kindof ticks me off about this "null is memory safe" 
argument; it seems to be only applicable to a specific platform 
and environment.  I have a micocontroller in front of me where an 
address of null (essentially 0) is a perfectly valid memory 
address.


Mike

Re: Shouldn't invalid references like this fail at compile time?

[Mike Franklin via Digitalmars-d]

On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer 
wrote:



Interestingly, `destroy` is an unsafe operation for classes.


Because it's calling a @system function, rt_finalize. This 
function calls whatever is in the destructor, and because it 
works on Object level, it has no idea what the actual 
attributes of the derived destructor are.


This needs to be fixed, but a whole host of issues like this 
exist with Object.


Are there any bugzilla issues that you are aware of that document 
this?


Mike

Re: wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[Jonathan M Davis via Digitalmars-d]

On Tuesday, January 23, 2018 23:27:27 Nathan S. via Digitalmars-d wrote:
> https://dlang.org/phobos/std_datetime_systime.html#.Clock.currStdTime
> """
> @property @trusted long currStdTime(ClockType clockType =
> ClockType.normal)();
> Returns the number of hnsecs since midnight, January 1st, 1 A.D.
> for the current time.
> """
>
> This choice of offset seems Esperanto-like: deliberately chosen
> to equally inconvenience every user. Is there any advantage to
> this at all on any platform, or is it just pure badness?

Your typical user would use Clock.currTime and get a SysTime. The badly
named "std time" is the internal representation used by SysTime. Being able
to get at it to convert to other time representations can be useful, but
most code doesn't need to do anything with it.

"std time" is from January 1st 1 A.D. because that's the perfect
representation for implementing ISO 8601, which is the standard that
std.datetime follows, implementing the proleptic Gregorian calendar (i.e. it
assumes that the calendar was always the Gregorian calendar and doesn't do
anything with the Julian calendar).

https://en.wikipedia.org/wiki/ISO_8601
https://en.wikipedia.org/wiki/Proleptic_Gregorian_calendar

The math is greatly simplified by using January 1st 1 A.D. as the start date
and by assuming Gregorian for the whole way.

C# does the same thing with its date/time stuff - it even uses
hecto-nanoseconds exactly like we do. hnsecs gives you the optimal balance
between precision and range that can be gotten with 64 bits (it covers from
about 22,000 B.C. to about 22,000 A.D., whereas IIRC, going one decimal
place more precise would reduce it to about 200 years in either direction).

- Jonathan M Davis

[Issue 18290] New: std.conv.parse throws ConvOverflowException for negative values in hex

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

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

  Issue ID: 18290
   Summary: std.conv.parse throws ConvOverflowException for
negative values in hex
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ru...@rumbu.ro

string input = "8000";
auto x = parse!int(input, 16);
//ConvOverflowException

--

Re: static function and access frame

[Alex via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 23:22:09 UTC, Steven Schveighoffer 
wrote:


So, if change the fun to static, it cannot pickup the pointer 
and therefore can't call anything of the aliased object. If I 
get it right...


I think so. But this is a guess, as the generated call clearly 
never uses that 'this' member. Interesting to me that it calls 
that member 'this', when 'this' is already defined!



Hmm... yes, I see...



cool option, by the way... didn't know anything about it. What 
does -ast do?


-vcg-ast means take the generated AST before optimization (I 
think), and output a d-source-like file (called file.d.cg) that 
shows the representation. Super useful when you are trying to 
figure out what the compiler does to your code. It only happens 
if compilation succeeds.


-ast, I don't think does anything, but not sure if that's what 
your question was.


The reason you don't know anything about it is because it's a 
debugging option and not documented :) At least, that's what I 
was told...



:)

If you click on the AST button on run.dlang.io, you get the 
same thing.




bug filed
https://issues.dlang.org/show_bug.cgi?id=18289

Thanks a lot.

Re: Developing blockchain software with D, not C++

[deadalnix via Digitalmars-d]

On Thursday, 18 January 2018 at 09:02:38 UTC, Walter Bright wrote:
I don't remember how long, but it took me a fair while to do 
the divide:


  https://github.com/dlang/druntime/blob/master/src/rt/llmath.d

It could be upscaled by rote to 128 bits, but even that would 
take me much longer than an hour. And it would still leave the 
issue of making ucent work with 32 bit code gen.


It could also be translated to D, but I doubt the generated 
code would be as good.


Nevertheless, we do have the technology, we just need someone 
to put it together.


All the code to split 64 bits into 32 bits was generic and could 
be reused.

[Issue 18289] New: static function and access frame

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

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

  Issue ID: 18289
   Summary: static function and access frame
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

According to the discussion here: 
https://forum.dlang.org/thread/qknxjxzbaowmsjdng...@forum.dlang.org
the following code should compile, but it does not. 

void main() // line 1
{
auto s = S();
auto t = T!s(); // line 4
t.fun;
}
struct S { void fun(){} }
struct T(alias s){ static fun() { s.fun; } } // line 8

The error is: 
source/app.d(8,35): Error: static function app.main.T!(s).T.fun cannot access
frame of function D main
source/app.d(4,14): Error: template instance app.main.T!(s) error instantiating

--

wut: std.datetime.systime.Clock.currStdTime is offset from Jan 1st, 1 AD

[Nathan S. via Digitalmars-d]

https://dlang.org/phobos/std_datetime_systime.html#.Clock.currStdTime
"""
@property @trusted long currStdTime(ClockType clockType = 
ClockType.normal)();
Returns the number of hnsecs since midnight, January 1st, 1 A.D. 
for the current time.

"""

This choice of offset seems Esperanto-like: deliberately chosen 
to equally inconvenience every user. Is there any advantage to 
this at all on any platform, or is it just pure badness?

Re: static function and access frame

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/23/18 6:08 PM, Alex wrote:

On Tuesday, 23 January 2018 at 22:59:31 UTC, Steven Schveighoffer wrote:

On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
I don't know the reason. You would think that accessing s would be 
relative to T.fun's stack frame, and have nothing to do with an 
instance of T.




using -vcg-ast gives a hint:

https://run.dlang.io/is/MZHPTY

Note that the T!(s) struct has a void *this member, that is probably 
the main stack frame pointer.




So, if change the fun to static, it cannot pickup the pointer and 
therefore can't call anything of the aliased object. If I get it right...


I think so. But this is a guess, as the generated call clearly never 
uses that 'this' member. Interesting to me that it calls that member 
'this', when 'this' is already defined!




cool option, by the way... didn't know anything about it. What does -ast 
do?


-vcg-ast means take the generated AST before optimization (I think), and 
output a d-source-like file (called file.d.cg) that shows the 
representation. Super useful when you are trying to figure out what the 
compiler does to your code. It only happens if compilation succeeds.


-ast, I don't think does anything, but not sure if that's what your 
question was.


The reason you don't know anything about it is because it's a debugging 
option and not documented :) At least, that's what I was told...


If you click on the AST button on run.dlang.io, you get the same thing.

-Steve

Re: Implementing tail-const in D

[sarn via Digitalmars-d]

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote:
Since tail-const (more correctly called head-mutable) was 
mentioned here lately (in the 'I closed a very old bug!'[1] 
thread), I've been racking my brain to figure out what needs 
doing to make a viable solution.


Have you seen Rebindable in Phobos?  I know it's not the same 
thing as what you're talking about, but it's relevant.

https://dlang.org/library/std/typecons/rebindable.html

Re: static function and access frame

[Alex via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 22:59:31 UTC, Steven Schveighoffer 
wrote:

On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
I don't know the reason. You would think that accessing s 
would be relative to T.fun's stack frame, and have nothing to 
do with an instance of T.




using -vcg-ast gives a hint:

https://run.dlang.io/is/MZHPTY

Note that the T!(s) struct has a void *this member, that is 
probably the main stack frame pointer.


-Steve


So, if change the fun to static, it cannot pickup the pointer and 
therefore can't call anything of the aliased object. If I get it 
right...


cool option, by the way... didn't know anything about it. What 
does -ast do?

Re: static function and access frame

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/23/18 5:52 PM, Steven Schveighoffer wrote:
I don't know the reason. You would think that accessing s would be 
relative to T.fun's stack frame, and have nothing to do with an instance 
of T.




using -vcg-ast gives a hint:

https://run.dlang.io/is/MZHPTY

Note that the T!(s) struct has a void *this member, that is probably the 
main stack frame pointer.


-Steve

Re: static function and access frame

[Alex via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 22:52:47 UTC, Steven Schveighoffer 
wrote:


No:

void main()
{
auto s = S();
auto t = T!s();
t.fun;
}
struct S { void fun(){} }
struct T(alias s){ static fun() { s.fun; } }

Fails in 2.078.

I don't know the reason. You would think that accessing s would 
be relative to T.fun's stack frame, and have nothing to do with 
an instance of T.


Right. This was the intention.



I would file a bug, and see what the compiler devs say.


ok, thanks.

Re: static function and access frame

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/23/18 5:33 PM, Ali Çehreli wrote:

On 01/23/2018 01:51 PM, Alex wrote:
 > Ok, I'm quite sure, I overlooked something.
 >
 > First version, working
 >
 > [code]
 > void main()
 > {
 >  auto s = S();
 >  auto t = T!s();
 >  t.fun;
 > }
 > struct S { void fun(){} }
 > struct T(alias s){ auto fun() { s.fun; } }
 > [/code]
 >
 > Now, the fun method of struct T has to become static and the problems
 > begin:
 > Error: static function app.main.T!(s).T.fun cannot access frame of
 > function D main

Good news: Works at least with 2.078 as it should:

void main()
{
     auto s = S();
     auto t = T!s();
     t.fun;
}
struct S { static void fun(){} }
struct T(alias s){ auto fun() { s.fun; } }

Ali



No:

void main()
{
auto s = S();
auto t = T!s();
t.fun;
}
struct S { void fun(){} }
struct T(alias s){ static fun() { s.fun; } }

Fails in 2.078.

I don't know the reason. You would think that accessing s would be 
relative to T.fun's stack frame, and have nothing to do with an instance 
of T.


I would file a bug, and see what the compiler devs say.

-Steve

Re: static function and access frame

[Alex via Digitalmars-d-learn]

On Tuesday, 23 January 2018 at 22:33:31 UTC, Ali Çehreli wrote:

On 01/23/2018 01:51 PM, Alex wrote:
> Ok, I'm quite sure, I overlooked something.
>
> First version, working
>
> [code]
> void main()
> {
>  auto s = S();
>  auto t = T!s();
>  t.fun;
> }
> struct S { void fun(){} }
> struct T(alias s){ auto fun() { s.fun; } }
> [/code]
>
> Now, the fun method of struct T has to become static and the
problems
> begin:
> Error: static function app.main.T!(s).T.fun cannot access
frame of
> function D main

Good news: Works at least with 2.078 as it should:

void main()
{
auto s = S();
auto t = T!s();
t.fun;
}
struct S { static void fun(){} }
struct T(alias s){ auto fun() { s.fun; } }

Ali


the other fun is meant to be static :)
so, the fun inside T.

Re: static function and access frame

[Ali Çehreli via Digitalmars-d-learn]

On 01/23/2018 01:51 PM, Alex wrote:
> Ok, I'm quite sure, I overlooked something.
>
> First version, working
>
> [code]
> void main()
> {
>  auto s = S();
>  auto t = T!s();
>  t.fun;
> }
> struct S { void fun(){} }
> struct T(alias s){ auto fun() { s.fun; } }
> [/code]
>
> Now, the fun method of struct T has to become static and the problems
> begin:
> Error: static function app.main.T!(s).T.fun cannot access frame of
> function D main

Good news: Works at least with 2.078 as it should:

void main()
{
auto s = S();
auto t = T!s();
t.fun;
}
struct S { static void fun(){} }
struct T(alias s){ auto fun() { s.fun; } }

Ali

static function and access frame

[Alex via Digitalmars-d-learn]

Ok, I'm quite sure, I overlooked something.

First version, working

[code]
void main()
{
auto s = S();
auto t = T!s();
t.fun;
}
struct S { void fun(){} }
struct T(alias s){ auto fun() { s.fun; } }
[/code]

Now, the fun method of struct T has to become static and the 
problems begin:
Error: static function app.main.T!(s).T.fun cannot access frame 
of function D main


Ok, found somewhere, that it could help to move the static 
function outside of the struct and tried this.


Second version, not working

[code]
void main()
{
auto s = S();
auto t = T!s();
fun!(typeof(t));
}
struct S { void fun(){} }
struct T(alias s){  }
auto fun(T : T!s, alias s)() { s.fun; }
[/code]

From my point of view, the second version is the most promising 
one, if there are problems with the first one. However, I didn't 
figured it out, how to match the alias template parameter to be 
able to call it from within the function fun (which is now at 
module level) directly.


Ok. Now, trying to find a solution I wrote the third version, 
working


[code]
void main()
{
auto s = S();
auto t = T!s();
fun(t);
}
struct S { void fun(){} }
struct T(alias s){ auto ss(){return s; } }
auto fun(T)(T t) { t.ss.fun; }
[/code]

Is this meant to be the right way? I mean, ok, if so, then, the 
way from different frames is a little bit verbose, but working. 
However, the fun method is meant to not use a specific object 
from the time point, where it was marked static. Why should I 
pass an instance to it?

Re: Shouldn't invalid references like this fail at compile time?

[Steven Schveighoffer via Digitalmars-d]

On 1/22/18 11:11 PM, Mike Franklin wrote:

On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:

Should `destroy` be `@system` so it can't be called in `@safe` code, 
or should the compiler be smart enough to figure out the flow control 
and throw an error?


Interestingly, `destroy` is an unsafe operation for classes.


Because it's calling a @system function, rt_finalize. This function 
calls whatever is in the destructor, and because it works on Object 
level, it has no idea what the actual attributes of the derived 
destructor are.


This needs to be fixed, but a whole host of issues like this exist with 
Object.



But it's not an unsafe operation for structs


Because struct destructors are not virtual. The compiler can tell when a 
struct destructor is unsafe:


https://run.dlang.io/is/o3ujrP

Note, I had to call destroy in a sub-function because if I made main 
@safe, it would fail to compile due to automatic destruction.




Not sure if that's a bug or not.


Not a bug.

Also, as others have pointed out, null dereferences are also considered 
@safe [1]. destroying an object doesn't actually deallocate it. It puts 
it into a state that is @safe to call, but will likely crash.


On 1/22/18 9:43 PM, Nicholas Wilson wrote:
>
> The compiler should be taught that any access to a `.destroy()`ed object
> is invalid i.e. that its lifetime ends when destroy is called.

destroy is just a function, there shouldn't be any special magic for it 
(we have enough of that already). And in fact its lifetime has not 
ended, it's just destructed, and left as an empty shell.


The idea behind destroy is to decouple destruction from deallocation (as 
delete combines the two). @safe is all about memory safety, nothing 
else. As long as you can't corrupt memory, it is @safe.


-Steve

[1] Note: the reason they are safe is because they generally result in a 
segfault, which doesn't harm any memory. This is very much a user-space 
POV, and doesn't take into account kernel-space where null dereferences 
may actually be valid memory! It also doesn't (currently) take into 
account possible huge objects that could extend into valid memory space, 
even in user space.

Re: Release D 2.078.1

[Rainer Schuetze via Digitalmars-d-announce]

On 23.01.2018 14:08, thedeemon wrote:

On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote:

Glad to announce D 2.078.1.



The Windows 7z archive version now has much simpler sc.ini, in fact too 
simple.

With Visual C++ 2015 x64 Native Build Tools now trying to run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.

Then it went just as 2.078.0 - still missing 
legacy_stdio_definitions.lib that I need to add manually in the command 
line.


The UCRT library path and legacy_stdio_definitions.lib should have been 
detected automatically.


I suspect that the Build Tools don't set the environment variable 
VisualStudioVersion (why should they?) which is used to detect whether 
the UCRT library path and legacy_stdio_definitions.lib are needed.


This PR https://github.com/dlang/dmd/pull/7500 would have fixed that by 
changing the detection to the existence of legacy_stdio_definitions.lib 
in the VC library path. Unfortunately it didn't make it into the 
release. (The PR contains other stuff, too, that was not meant to go 
into a .1 release.)


(Having VS installed would help, too, as it is also detected without the 
environment set.)

Vision for 2018 H1?

[Dukc via Digitalmars-d]

Is it intended to be updated? No pressure, just making sure it's 
not forgotten...

Re: LDC 1.7.0

[kinke via Digitalmars-d-announce]

On Sunday, 21 January 2018 at 15:38:02 UTC, Johannes Loher wrote:

On Sunday, 21 January 2018 at 12:00:32 UTC, kinke wrote:
In the meantime, I started an LLVM 5.0.1 build in my qemu 
emulator 12 hours ago; one third has been compiled so far, so 
you may expect the armhf package to be available tomorrow or 
the day after that.


That is great news to me, thank you very much for your effort!


You're welcome; it's up now.

[Issue 15275] Documentation for OutputRange lacking

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

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

Jack Stouffer  changed:

   What|Removed |Added

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

--- Comment #2 from Jack Stouffer  ---
With the recent and already mentioned improvements to the docs I'm marking this
as resolved

--

[Issue 18287] several std.math functions no longer work with alias this

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

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

--- Comment #1 from hst...@quickfur.ath.cx ---
Has signbit() ever worked with alias this types?  I tried commenting out the
new sig constraint of signbit(), but this code still fails to compile on git
master:


struct Proxy {
double f;
alias f this;
}
auto p = Proxy(1.61803);
auto sign = signbit(p);


The compiler says:
-
std/math.d(267): Error: cannot implicitly convert expression 4.50360e+15 of
type double to Proxy
std/math.d(5762): Error: template instance std.math.floatTraits!(Proxy) error
instantiating
std/math.d(5806):instantiated from here: signbit!(Proxy)


This is caused by signbit() attempting to instantiate floatTraits with Proxy,
but floatTraits does not take alias this into account.

(Not that it *shouldn't* work with alias this, but just that it doesn't seem to
have worked before. Or perhaps that only broke after floatTraits was
introduced?)

--

Re: [dlang library documentation] Why there are dlang.org/library and dlang.org/phobos?

[Seb via Digitalmars-d-learn]

On Monday, 22 January 2018 at 19:38:45 UTC, John Gabriele wrote:

On Monday, 22 January 2018 at 15:32:29 UTC, Adam D. Ruppe wrote:

On Monday, 22 January 2018 at 15:18:38 UTC, Johann wrote:

Maybe it's due to historical reasons.


It's actually "future" reasons... the /phobos is the original 
one, and /library was supposed to replace it, but now many 
years later, /library is still kinda neglected and they both 
just exist.


What's needed to remove the "/phobos" one? Is it a decision 
from on-high, or is there a lot of editing of hardcoded links 
required?


This discussion and the referenced news group thread should give 
insights:


https://github.com/dlang/dlang.org/pull/1526

BTW the fix for your issue is here:

https://github.com/dlang/phobos/pull/6055

[Issue 18287] several std.math functions no longer work with alias this

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

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

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

   What|Removed |Added

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

--

Re: dub release package

[Ali Çehreli via Digitalmars-d-announce]

On 01/23/2018 07:41 AM, Arun Chandrasekaran wrote:
The post creation page could hint to which forum 
we are posting, something like this: https://i.imgur.com/8LgLsx8.png


Even better, but perhaps controversial, the "Send" button could say 
"Send to Announce Group".


Ali

[Issue 18288] std.algorithm.comparison.cmp for wide strings should be @safe

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

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

Nathan S.  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 18288] New: std.algorithm.comparison.cmp for wide strings should be @safe

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

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

  Issue ID: 18288
   Summary: std.algorithm.comparison.cmp for wide strings should
be @safe
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Sample code that does not currently compile:
https://run.dlang.io/is/EG6kdu
```
void main() @safe
{
import std.algorithm.comparison : cmp;
assert(cmp("aaa"d, "aaa"d) == 0);
}
```

--

[Issue 17899] Cannot initialise contextless delegate at compile time

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

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

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

   What|Removed |Added

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

--

[Issue 17899] Cannot initialise contextless delegate at compile time

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

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

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

https://github.com/dlang/dmd/commit/a552d6552d44de9284f03815ecfb32585f0186ac
Fix Issue 17899 - Cannot initialise contextless delegate at compile time

Also revert test case for 13259 - there is no reason that initialised
module scope delegates should be illegal.

https://github.com/dlang/dmd/commit/8476f8bb4e59e92ed8b01bcd7513066aae172139
Merge pull request #7704 from thewilsonator/patch-2

Fix Issue 17899: Allow delegate initialisation at module scope

--

[Issue 14336] Invalid memory access in struct destructor in std.uni

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--- Comment #3 from Carsten Blüggel  ---
Maybe the following PR is related (or close to) this issue?
It jail's previously possible (as per dmd analysis) escaping this.data pointer
through InversionList.byInterval() with -dip1000.
https://github.com/dlang/phobos/pull/6041

--

[Issue 17630] selective imports find symbols in private imports of other modules

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

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

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

   What|Removed |Added

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

--

[Issue 17630] selective imports find symbols in private imports of other modules

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

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

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

https://github.com/dlang/dmd/commit/7d23df1a037545ffed3b8632f2d84fa062573b77
Fix Issue 17630 - selective imports find symbols in private imports of other
modules

https://github.com/dlang/dmd/commit/52d26744cf6d6241d514f47c02cc35152412adda
Merge pull request #7760 from RazvanN7/Issue_17630

Fix Issue 17630 - selective imports find symbols in private imports o…
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: Tuple DIP

[Atila Neves via Digitalmars-d]

On Tuesday, 23 January 2018 at 14:58:07 UTC, Petar Kirov 
[ZombineDev] wrote:

On Tuesday, 23 January 2018 at 11:04:33 UTC, Atila Neves wrote:

On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:

On 14.01.2018 19:14, Timothee Cour wrote:
actually I just learned that indeed 
sizeof(typeof(tuple()))=1, but why

is that? (at least for std.typecons.tuple)
maybe worth mentioning that in the DIP (with rationale)


It's inherited from C, where all struct instances have size 
at least 1. (Such that each of them has a distinct address.)


Inherited from C++. In C empty structs have size 0. This 
caused me all sorts of problems when importing C headers from 
C++ in funky codebases.


foo.c:
#include 

struct Foo {};

int main() {
printf("%zu\n", sizeof(struct Foo));
return 0;
}


% clear && gcc foo.c && ./a.out
0

% clear && gcc -xc++ foo.c && ./a.out
1


Atila


AFAIR the ISO C standard does not allow empty structs (as they 
would have no meaning). If you use the warnings as errors 
option, it won't compile:


:3:8: error: struct has no members [-Werror=pedantic]
 struct Foo {};
^~~


That's a warning treated as error. I checked and it seems that 
you're right about the C standard, although in practice compilers 
seem to accept empty structs. I knew that in C++ it's explicit 
that empty classes have size 1. Live and learn.


Atila

[Issue 18243] selective import + overload = private visibility

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

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

--- Comment #5 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/7766

--

Re: dub release package

[Basile B. via Digitalmars-d-announce]

On Tuesday, 23 January 2018 at 15:41:37 UTC, Arun Chandrasekaran 
wrote:

On Tuesday, 23 January 2018 at 00:24:46 UTC, Seb wrote:

Also please don't post questions to Announce!
https://github.com/dlang/dub/issues would have been the right 
place.


Ah, I thought I was posting to General. Sorry about that. I see 
similar posts though not often. The post creation page could 
hint to which forum we are posting, something like this: 
https://i.imgur.com/8LgLsx8.png


DUB as a binary is provided with each new DMD or LDC release, 
that is the reason why there is no binaries (called assets now) 
on the GH page. If you setup a D compiler you have DUB 
automatically nowadays.

Re: dub release package

[Arun Chandrasekaran via Digitalmars-d-announce]

On Tuesday, 23 January 2018 at 00:24:46 UTC, Seb wrote:

Also please don't post questions to Announce!
https://github.com/dlang/dub/issues would have been the right 
place.


Ah, I thought I was posting to General. Sorry about that. I see 
similar posts though not often. The post creation page could hint 
to which forum we are posting, something like this: 
https://i.imgur.com/8LgLsx8.png

Re: Release D 2.078.1

[Andre Pany via Digitalmars-d-announce]

On Tuesday, 23 January 2018 at 13:08:35 UTC, thedeemon wrote:

On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote:

Glad to announce D 2.078.1.



The Windows 7z archive version now has much simpler sc.ini, in 
fact too simple.

With Visual C++ 2015 x64 Native Build Tools now trying to run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.

Then it went just as 2.078.0 - still missing 
legacy_stdio_definitions.lib that I need to add manually in the 
command line.


Did you call vcvarsall in the current dos box/PowerShell? It is a 
tool included with all visual studio variants.


Kind regards
Andre

Re: Tuple DIP

[Petar via Digitalmars-d]

On Tuesday, 23 January 2018 at 11:04:33 UTC, Atila Neves wrote:

On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:

On 14.01.2018 19:14, Timothee Cour wrote:
actually I just learned that indeed 
sizeof(typeof(tuple()))=1, but why

is that? (at least for std.typecons.tuple)
maybe worth mentioning that in the DIP (with rationale)


It's inherited from C, where all struct instances have size at 
least 1. (Such that each of them has a distinct address.)


Inherited from C++. In C empty structs have size 0. This caused 
me all sorts of problems when importing C headers from C++ in 
funky codebases.


foo.c:
#include 

struct Foo {};

int main() {
printf("%zu\n", sizeof(struct Foo));
return 0;
}


% clear && gcc foo.c && ./a.out
0

% clear && gcc -xc++ foo.c && ./a.out
1


Atila


AFAIR the ISO C standard does not allow empty structs (as they 
would have no meaning). If you use the warnings as errors option, 
it won't compile:


:3:8: error: struct has no members [-Werror=pedantic]
 struct Foo {};
^~~

Re: Implementing tail-const in D

[Simen Kjærås via Digitalmars-d]

On Tuesday, 23 January 2018 at 14:17:26 UTC, Andrea Fontana wrote:

On Tuesday, 23 January 2018 at 12:39:12 UTC, Simen Kjærås wrote:
On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson 
wrote:
On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås 
wrote:

Questions: Is a DIP required for this?


A DIP is required for language changes. So yes.


No language changes are proposed - this is all library code.

--
  Simen


It would be useful to have one or more short examples. Just to 
see what actually change in a common scenario.


Andrea


Your wish is my command. For the most part, the changes will 
require that instead of storing Unqual!Ts, use HeadMutable!Ts, 
and when assigning to a HeadMutable!T, remember to assign 
headMutable(rhs).


Here's a somewhat simplistic map function. As you can see, not a 
whole lot is changed - map passes head-mutable versions of its 
arguments to MapResult, and MapResult implements opHeadMutable(), 
otherwise everything is exactly as you'd expect.


import std.range;

auto map(alias fn, R)(R r) if (isInputRange!(HeadMutable!R))
{
// Pass head-mutable versions to MapResult.
return MapResult!(fn, HeadMutable!R)(headMutable(r));
}

struct MapResult(alias fn, R) if (isInputRange!R)
{
R range;

this(R rng)
{
range = rng;
}

@property
auto front()
{
return fn(range.front);
}

void popFront()
{
range.popFront();
}

@property
bool empty()
{
return range.empty;
}

// The only change to MapResult:
auto opHeadMutable(this This)()
{
import std.traits : CopyTypeQualifiers;
return MapResult!(fn, 
HeadMutable!(CopyTypeQualifiers!(This, R)))(range);

}
}


unittest
{
import std.algorithm : equal;

const a = [1,2,3,4].map!(v => v*2);
assert(!isInputRange!(typeof(a)));

// Here, std.algorithm.map gives up, since a const MapResult 
is not
// an input range, and calling Unqual on it doesn't give a 
sensible

// result.
// HeadMutable makes this work, since the type system now 
knows how

// to make a head-mutable version of the type.
auto b = a.map!(v => v/2);

assert(equal([1,2,3,4], b));
}

--
  Simen

Hopper for low level D debug

[Basile B. via Digitalmars-d-debugger]

Hopper

https://www.hopperapp.com/

Is not so bad for low level debugging (à la IDA).
The symbols are not demangled however.
I've recently used it to check a call to SDL in a D app:

https://imgur.com/a/vsJiu

The integrated debugger is actually using GDB (at least on linux).

Re: Implementing tail-const in D

[Andrea Fontana via Digitalmars-d]

On Tuesday, 23 January 2018 at 12:39:12 UTC, Simen Kjærås wrote:
On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson 
wrote:
On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås 
wrote:

Questions: Is a DIP required for this?


A DIP is required for language changes. So yes.


No language changes are proposed - this is all library code.

--
  Simen


It would be useful to have one or more short examples. Just to 
see what actually change in a common scenario.


Andrea

[your code here]8a0c0767f3c37500

[aicha via Digitalmars-d]

credi
ts 9;999

[Issue 16509] DIP25 'return' attribute not documented for functions

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

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

Mathias Lang  changed:

   What|Removed |Added

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

--- Comment #2 from Mathias Lang  ---
Indeed!

--

Re: Release D 2.078.1

[thedeemon via Digitalmars-d-announce]

On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote:

Glad to announce D 2.078.1.



The Windows 7z archive version now has much simpler sc.ini, in 
fact too simple.

With Visual C++ 2015 x64 Native Build Tools now trying to run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.

Then it went just as 2.078.0 - still missing 
legacy_stdio_definitions.lib that I need to add manually in the 
command line.

[Issue 16509] DIP25 'return' attribute not documented for functions

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--- Comment #1 from Carsten Blüggel  ---
There is https://dlang.org/spec/function.html#return-ref-parameters
I suggest RESOLVED FIXED

--

Re: Implementing tail-const in D

[Simen Kjærås via Digitalmars-d]

On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson 
wrote:

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote:

Questions: Is a DIP required for this?


A DIP is required for language changes. So yes.


No language changes are proposed - this is all library code.

--
  Simen

Re: Implementing tail-const in D

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote:

Questions: Is a DIP required for this?


A DIP is required for language changes. So yes.

[Issue 16783] std.net.curl application throws an exception

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

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

Aravinda  changed:

   What|Removed |Added

 CC||hallimanearav...@gmail.com

--- Comment #6 from Aravinda  ---
Easy to reproduce if URL is invalid or the server is down

import std.net.curl, std.stdio;

void main()
{
foreach (line; byLineAsync("dlang.org1"))
writeln(line);
}

I think patch required to raise proper exception.

--

Re: Tuple DIP

[Atila Neves via Digitalmars-d]

On Sunday, 14 January 2018 at 18:17:38 UTC, Timon Gehr wrote:

On 14.01.2018 19:14, Timothee Cour wrote:
actually I just learned that indeed sizeof(typeof(tuple()))=1, 
but why

is that? (at least for std.typecons.tuple)
maybe worth mentioning that in the DIP (with rationale)


It's inherited from C, where all struct instances have size at 
least 1. (Such that each of them has a distinct address.)


Inherited from C++. In C empty structs have size 0. This caused 
me all sorts of problems when importing C headers from C++ in 
funky codebases.


foo.c:
#include 

struct Foo {};

int main() {
printf("%zu\n", sizeof(struct Foo));
return 0;
}


% clear && gcc foo.c && ./a.out
0

% clear && gcc -xc++ foo.c && ./a.out
1


Atila

[Issue 18287] New: several std.math functions no longer work with alias this

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

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

  Issue ID: 18287
   Summary: several std.math functions no longer work with alias
this
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

https://github.com/dlang/phobos/pull/6040/files changed several functions
(signbit, isFinite, isNormal, isSubnormal, sign, nextAfter and approxEqual to
enforce type matching, meaning that all alias-this types no longer work with
them

--

Implementing tail-const in D

[Simen Kjærås via Digitalmars-d]

Since tail-const (more correctly called head-mutable) was 
mentioned here lately (in the 'I closed a very old bug!'[1] 
thread), I've been racking my brain to figure out what needs 
doing to make a viable solution.


Unqual is the standard way today to get a head-mutable version of 
something. For dynamic arrays, static arrays, pointers and value 
types, including structs without aliasing, thi works. For AAs, 
classes, and structs with aliasing, Unqual is the wrong tool, but 
it's the tool we have, so it's what we use.


Unqual has other uses, so HeadMutable!T should be a separate 
template. This means parts of Phobos will need to be reworked to 
support types not currently supported. However, given these types 
are not currently supported, this should not break any existing 
code.


While it is generally desirable for T to be implicitly castable 
to HeadMutable!T (just like const(int[]) is implicitly castable 
to const(int)[]), the rules for such implicit casting in the 
language today are inconsistent[2] and incompatible with alias 
this[3], opDispatch, opDot, subclassing, and constructors.


Instead of implicit casting, I therefore propose we use a method 
headMutable(), which will attempt to call the appropriate 
functions to do the conversion. With these two building blocks, 
we have what we need for tail-const (head-mutable) ranges and 
other constructs.


What does your code need to do to support HeadMutable? If you 
have a templated struct that holds an array or pointer, the type 
of which depends on a template parameter, you can define a 
function opHeadMutable that returns a head-mutable version. 
That's it.


If you use HeadMutable!T anywhere, you almost definitely should 
use headMutable() when assigning to it, since T might not be 
implicitly castable to HeadMutable!T.


So what does all of this look like? An example templated struct 
with opHeadMutable hook:


struct R(T) {
T[] arr;
auto opHeadMutable(this This)() {
import std.traits : CopyTypeQualifiers;
return R!(CopyTypeQualifiers!(This, T))(arr);
}
}

This is the code you will need to write to ensure your types can 
be converted to head-mutable. opHeadMutable provides both a 
method for conversion, and a way for the HeadMutable!T template 
to extract the correct type.


The actual implementation of HeadMutable!T and headMutable is 
available here:

https://gist.github.com/Biotronic/67bebfe97f17e73cc610d9bcd119adfb


My current issues with this:
1) I don't like the names much. I called them Decay, decay and 
opDecay for a while. Name suggestions are welcome.
2) As mentioned above, implicit conversions would be nice, but 
that'd require an entirely new type of implicit conversion in 
addition to alias this, opDispatch, opDot and interfaces/base 
classes. This would require some pretty darn good reasons, and I 
don't think a call to headMutable() is that much of a problem.


Questions:
Is a DIP required for this? Should I create a PR implementing 
this for the range types in Phobos? What other types would 
benefit from this?


I welcome any and all... feck it. Destroy!

--
  Simen

[1]: 
https://forum.dlang.org/post/egpcfhpediicvkjuk...@forum.dlang.org

[2]: https://issues.dlang.org/show_bug.cgi?id=18268
[3]: Alias this is too eager, and allows for calling mutating 
methods on the temporary value it returns. If alias this was used 
to allow const(int[]) to convert to const(int)[], 
isInputRange!(const(int[])) would return true.

Re: Please provide a channel for D ecosystem ideas

[JN via Digitalmars-d]

On Saturday, 20 January 2018 at 20:37:45 UTC, Andre Pany wrote:

Hi,

the GSOC wiki page inspired me to write this request. If I have 
an idea how the improve the D ecosystem but cannot do it 
myself, there is at the moment no good channel to provide this 
idea to someone other in the D community. Maybe someone other 
is searching for an opportunity to help the D ecosystem but 
does not know how.


In the past, dsource used to serve this purpose. It was during 
the Tango vs Phobos times, but there were so many projects being 
born, each project had a separate webforum where people could 
discuss stuff. I feel like we are missing something now. Gtkd has 
its own forums, vibed has its own, most other projects are on 
github where discussion is hidden behind issues section.


I think wiki could work, or just a subsection of this forum here.

[Issue 18282] [Scope][DIP1000]Assignment of local variable to `scope` variable not recognized by compiler

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

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

Mike Franklin  changed:

   What|Removed |Added

Summary|Assignment of local |[Scope][DIP1000]Assignment
   |variable to `scope` |of local variable to
   |variable not recognized by  |`scope` variable not
   |compiler|recognized by compiler

--

[Issue 18282] Assignment of local variable to `scope` variable not recognized by compiler

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

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||safe

--

Re: Shouldn't invalid references like this fail at compile time?

[Kagamin via Digitalmars-d]

On Monday, 22 January 2018 at 23:30:16 UTC, Aedt wrote:
I was asked in Reddit 
(https://www.reddit.com/r/learnprogramming/comments/7ru82l/i_was_thinking_of_using_d_haxe_or_another/) how would D handle the following similar D code. I'm surprised that both dmd and ldc provides no warnings even with -w argument passed.


Well, if you want to check much at compile time, you probably 
want SPARK or F* (fstar).

[Issue 18283] -dip1000 doesn't catch invalid local reference

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

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

anonymous4  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from anonymous4  ---
destroy for pointer assigns null to it, it's safe. Dereferencing null pointer
is safe too, because it doesn't lead to memory corruption in protected memory
environment.

--

[Issue 18281] Compiler rejects safe code in @safe

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

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

anonymous4  changed:

   What|Removed |Added

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

--- Comment #1 from anonymous4  ---
I believe accepting all Turing-complete safe code would require solution to
halting problem, so type system is necessarily conservative: what passes is
safe, but so much about it. DIP1000 extends scope of accepted safe code.

--