[Issue 17691] core.mutex.Mutex : {lock,unlock} should be @nogc

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||petar.p.ki...@gmail.com
   Hardware|x86_64  |All
 Resolution|--- |WONTFIX
 OS|Linux   |All

--- Comment #1 from ZombineDev  ---
Since those functions are virtual, adding any attribute to them is breaking
change, because it adds additional requirements to derived classes.

New code that doesn't need to use derived classes, should prefer the `final`
alternatives (lock_nothrow, tryLock_nothrow and unlock_nothrow). This violates
the "open" part of OCP, so a valid, though probably unrelated to your problem,
enhancement request is to create a class derived from Mutex that has all the
attributes, but allows those methods to be overridden.

--

Re: Get UDA of unit tests during Runtime.moduleUnitTester

[Seb via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 03:27:30 UTC, Matthew Remmel wrote:
I'd like to print out the name given to a unit test via a UDA, 
as the tests are being ran by the Runtime.moduleUnitTester. I'm 
working on writing a custom unit test runner. It would seem 
that the ModuleInfo.unitTest property is an aggregated function 
of all the individual unit test blocks in a module, and 
therefore the UDA value is lost.


[...]



Do you know https://github.com/atilaneves/unit-threaded?

Re: [OT] Re: strong typing for browser code [Was: D easily overlooked?]

[Neia Neutuladh via Digitalmars-d]

On Tuesday, 25 July 2017 at 10:27:43 UTC, Russel Winder wrote:
There is little traction in a browser-focused language that 
doesn't offer a massive USP over JavaScript/ECMAScript – typing 
is the only USP over ES6 that has any chance really. Elm, 
Kotlin, Ceylon, etc. are already populating the market. I 
suspect Dart will have little hope for traction now.


While Elm and Kotlin get a decent amount of press, Dart is 
scoring well on Github and TIOBE.

[Issue 17430] [scope] delegate can escape context ptr

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7027

--

Get UDA of unit tests during Runtime.moduleUnitTester

[Matthew Remmel via Digitalmars-d-learn]

I'd like to print out the name given to a unit test via a UDA, as 
the tests are being ran by the Runtime.moduleUnitTester. I'm 
working on writing a custom unit test runner. It would seem that 
the ModuleInfo.unitTest property is an aggregated function of all 
the individual unit test blocks in a module, and therefore the 
UDA value is lost.


I've been attempting to use the __traits(getUnitTests, m) 
function, but that doesn't seem to work with ModuleInfo because 
it is a variable and not a symbol. Additionally, if you run 
__traits(getUnitTests, m) against a module, that doesn't retrieve 
any unit tests that are nested inside classes or structs. So even 
if it did work with ModuleInfo, there may still be problems.


What I would like is to have a module like:
___
module app;

int square(int x) { return x*x; }

@name("square test 1")
unittest {
assert(square(10) == 100);
}

@name("square test 2")
unittest {
assert(square(5) == 25);
}

class Foo {
void someFunc() { return; }

@name("Foo test")
unittest {
assert(someFunc() == something);
}
}
___

So as mentioned above, the first problem is that using 
ModuleInfo.unitTest returns an aggregated function of all 3 unit 
tests for that module, instead of each one individually, so the 
UDA information is lost. The second problem is that running 
__traits(getUnitTests, app) only returns the 2 tests at module 
scope, and not the one nested inside Foo. Even then, I haven't 
been able to figure out how to dynamically get the module symbol 
to pass to __traits inside of the Runtime.moduleUnitTester 
function.


Its possible that I've got some of this backwards and there is an 
easy solution. Its also possible that what i'm trying to do isn't 
currently possible.


Thanks in advance for any help.
--Matt

Re: all OS functions should be "nothrow @trusted @nogc"

[Walter Bright via Digitalmars-d]

On 7/25/2017 6:09 PM, Steven Schveighoffer wrote:
Likewise, because D depends on hardware flagging of dereferencing null as a 
segfault, any platforms that *don't* have that for C also won't have it for D. 
And then @safe doesn't even work in D code either.


I spent 10 years programming on DOS with zero memory protection, and people have 
forgotten how awful that was. You couldn't simply instrument the code with null 
pointer checks, either, because then the program would be too big to fit.


The solution finally appeared with the 286 DOS Extenders, which ran in protected 
mode. I switched to doing all my development under them, and would port to DOS 
only after passing all the test suite.


D is definitely predicated on having hardware memory protection.

The C/C++ Standards are still hanging on to EBCDIC, 10 bit bytes, non-IEEE 
floating point, etc. It's time to let that crap go :-)


One C++ programmer told me that C++ could handle any character set. I asked him 
how RADIX50 was supported. Segfault! (I learned to program on RADIX50 systems.)


D made some fundamental decisions:

* Unicode
* 2's complement
* 8 bit bytes
* IEEE arithmetic
* memory protection
* fixed sizes for integral types
* single pointer type
* >= 32 bit processors

that relegated a lot of junk to the dustbin of history. (It's awful pretending 
to support that stuff. C and C++ pretend do, but just about zero programs will 
actually work on such systems, because there aren't any to try the code out on.)

Re: all OS functions should be "nothrow @trusted @nogc"

[Walter Bright via Digitalmars-d]

On 7/25/2017 5:56 PM, Andrei Alexandrescu wrote:
I'd think that would be the case, but failed to find a fgetc implementation that 
mentions it's undefined for a null FILE*. Is there a link? Thx. -- Andrei


The documentation for DMC++ fgetc() is:

  https://digitalmars.com/rtl/stdio.html#fgetc

and says:

  "Returns the character just read on success, or EOF if end-of-file or a read 
error is encountered."


The implementation checks for fp being NULL and returns EOF if it is.

Re: Destructors vs. Finalizers

[Mike Parker via Digitalmars-d]

On Wednesday, 26 July 2017 at 02:58:00 UTC, Mike Parker wrote:


Internally, the runtime will treat each differently. an 
rt_destruct would call all every __dtor in a hierarchy and 
rt_finalize would be changed to call every __finalizer (a new 
addition) in a hierarchy. When cleaning up, the GC will ensure 
that all destructors are run where they exist, followed by all 
finalizers. And destroy would be changed to call rt_destruct 
instead of rt_finalize.


Thoughts?


And an important bit I left out -- destroy would still call 
rt_finalize if no destructor is present, which would preserve 
current behavior.

Destructors vs. Finalizers

[Mike Parker via Digitalmars-d]

Regarding the issue with `destroy` not being @nogc, I my 
understanding is it comes down to `rt_finalize` not being @nogc. 
I haven't dug too deeply into the discussions around it, but I'm 
wondering if it's possible to separate the concept of destruction 
from finalization in the implementation?


Externally, we can do it with the existing language:

class {
~this() {} // Finalizer

~this @nogc {} // Destructor
}

Internally, the runtime will treat each differently. an 
rt_destruct would call all every __dtor in a hierarchy and 
rt_finalize would be changed to call every __finalizer (a new 
addition) in a hierarchy. When cleaning up, the GC will ensure 
that all destructors are run where they exist, followed by all 
finalizers. And destroy would be changed to call rt_destruct 
instead of rt_finalize.


Thoughts?

Re: all OS functions should be "nothrow @trusted @nogc"

[Walter Bright via Digitalmars-d]

On 7/25/2017 8:26 AM, Andrei Alexandrescu wrote:

A suite of safe wrappers on OS primitives might be useful.


The idea of fixing the operating system interface(s) has come up now and then. 
I've tried to discourage that on the following grounds:



* We are not in the operating system business.

* Operating system APIs grow like weeds. We'd set ourselves an impossible task.

* It's a huge job simply to provide accurate declarations for the APIs.

* We'd have to write our own documentation for the operating system APIs. It's 
hard enough writing such for Phobos.


* A lot are fundamentally unfixable, like free() and strlen().

* The API import files should be focused solely on direct access to the APIs, 
not adding a translation layer. The user of them will expect this.


* We already have safe wrappers for the commonly used APIs. For read(), there is 
std.stdio.



It is worthwhile, however, to augment the APIs with the appropriate attributes 
like @nogc, scope, nothrow, @safe (for the ones that are), etc.

Re: [your code here] Pure RPN calculator

[Seb via Digitalmars-d]

On Tuesday, 25 July 2017 at 21:13:54 UTC, Max Haughton wrote:
Semi-Functional/pure RPN calculator: 
https://run.dlang.io/is/JGkBZx


This is probably too long, but it demonstrates the compiler 
enforced safety and purity (State is passed through the fold), 
while also showing off the higher level parts of Phobos (Use of 
fold).


Max, this is a great example!
However, as you noticed it's a bit long and in fact in its 
current state it wouldn't look good:


http://imgur.com/a/KwczM

If there's no chance to make it shorter, my suggestion 
considering that there are two other ideas in the queue with a 
similar length problem:


https://github.com/dlang/dlang.org/pull/1759
https://github.com/dlang/dlang.org/pull/1762

would be to find a new home for such "one-page" D example. We 
plan to restructure the DTour (tour.dlang.org) anyways, so how 
about adding a new section like "D in action" to it?


-> I have opened a discussion: 
https://github.com/dlang-tour/english/issues/194

Re: I feel the dynamic array .sizeof property is kind of a bait and switch

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:

Static Arrays have property
.sizeof which returns the array length multiplied by the number 
of bytes per array element.


Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference, 
which is 8 in 32-bit builds and 16 on 64-bit builds.


Both actually already do exactly the same thing: .sizeof returns 
the size of the variable. Same thing with pointers, class 
references, and everything else.


I've hand rolled a function which is working for me currently, 
but with my coding ability, I'd feel much safer with something 
official :)


You could also do (cast(ubyte[]) array).length.

It just seems like something this basic regarding dynamic 
arrays should just be built-in.


What are you using it for?

Re: I feel the dynamic array .sizeof property is kind of a bait and switch

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:

Static Arrays have property
.sizeof which returns the array length multiplied by the number 
of bytes per array element.


Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference, 
which is 8 in 32-bit builds and 16 on 64-bit builds.


Why not have dynamic arrays with a .sizeof identical to static 
arrays and say another property called .sizeref which handles 
the 32 or 64 bit references.


Maybe Phobos has something that I'm not aware of?

I've hand rolled a function which is working for me currently, 
but with my coding ability, I'd feel much safer with something 
official :)


It just seems like something this basic regarding dynamic 
arrays should just be built-in.


Because .sizeof has nothing to do with how many elements are in 
the array. It tells you how much space the array itself takes up. 
With static arrays, the memory for the elements if part of the 
array itself, so it is counted in the size. For dynamic arrays, 
it is not. For .sizeof to report the size of the allocated memory 
would be incorrect.

I feel the dynamic array .sizeof property is kind of a bait and switch

[WhatMeForget via Digitalmars-d-learn]

Static Arrays have property
.sizeof which returns the array length multiplied by the number 
of bytes per array element.


Dynamic Arrays have property
.sizeof which returns the size of the dynamic array reference, 
which is 8 in 32-bit builds and 16 on 64-bit builds.


Why not have dynamic arrays with a .sizeof identical to static 
arrays and say another property called .sizeref which handles the 
32 or 64 bit references.


Maybe Phobos has something that I'm not aware of?

I've hand rolled a function which is working for me currently, 
but with my coding ability, I'd feel much safer with something 
official :)


It just seems like something this basic regarding dynamic arrays 
should just be built-in.

Re: Problem with integral promotions

[Walter Bright via Digitalmars-d]

On 7/25/2017 6:43 AM, Steven Schveighoffer wrote:
However, if C operates this way, this would be a huge trap for people who are 
porting code.


That's right. Also for C/C++ programmers who are used to how C works.

[Issue 17691] New: core.mutex.Mutex : {lock,unlock} should be @nogc

[via Digitalmars-d-bugs]

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

  Issue ID: 17691
   Summary: core.mutex.Mutex : {lock,unlock} should be @nogc
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Their underlying implementations are already @nogc.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 8:45 PM, Timon Gehr wrote:

On 26.07.2017 02:35, Steven Schveighoffer wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) specific 
implementation detail (it's what you generally expect to happen, but 
AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D would 
not crash when dereferencing null. D depends on the hardware doing 
this (Walter has said so many times), so if C doesn't do it, then D 
won't. So those systems would have to be treated specially, and you'd 
have to work out your own home-grown mechanism for memory safety.


What Moritz is saying is that the following implementation of fclose is 
correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 go_wild_and_corrupt_all_the_memory();
 }else{
 actually_close_the_file(stream);
 }
}


I think we can correctly assume no fclose implementations exist that do 
anything but access data pointed at by stream. Which means a segfault on 
every platform we support.


On platforms that may not segfault, you'd be on your own.

In other words, I think we can assume for any C functions that are 
passed pointers that dereference those pointers, passing null is safely 
going to segfault.


Likewise, because D depends on hardware flagging of dereferencing null 
as a segfault, any platforms that *don't* have that for C also won't 
have it for D. And then @safe doesn't even work in D code either.


As we have good support for different prototypes for different 
platforms, we could potentially unmark those as @trusted in those cases.


-Steve

Re: [your code here] Pure RPN calculator

[GrrrrrAngryMan via Digitalmars-d]

On Tuesday, 25 July 2017 at 21:13:54 UTC, Max Haughton wrote:
Semi-Functional/pure RPN calculator: 
https://run.dlang.io/is/JGkBZx


This is probably too long, but it demonstrates the compiler 
enforced safety and purity (State is passed through the fold), 
while also showing off the higher level parts of Phobos (Use of 
fold).


Answer to this 
https://forum.dlang.org/post/dhuvztizmqysqsepm...@forum.dlang.org.

This is exactly what the author looked for.

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/25/2017 08:45 PM, Timon Gehr wrote:

On 26.07.2017 02:35, Steven Schveighoffer wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) specific 
implementation detail (it's what you generally expect to happen, but 
AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D would 
not crash when dereferencing null. D depends on the hardware doing 
this (Walter has said so many times), so if C doesn't do it, then D 
won't. So those systems would have to be treated specially, and you'd 
have to work out your own home-grown mechanism for memory safety.


What Moritz is saying is that the following implementation of fclose is 
correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 go_wild_and_corrupt_all_the_memory();
 }else{
 actually_close_the_file(stream);
 }
}


I'd think that would be the case, but failed to find a fgetc 
implementation that mentions it's undefined for a null FILE*. Is there a 
link? Thx. -- Andrei

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 02:45, Timon Gehr would have liked to have written:

...
What Moritz is saying is that the following implementation of fclose is 
correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 return go_wild_and_corrupt_all_the_memory();
 }else{
 return actually_close_the_file(stream);
 }
}


(Forgot the returns.)

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 26.07.2017 02:35, Steven Schveighoffer wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) specific 
implementation detail (it's what you generally expect to happen, but 
AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D would 
not crash when dereferencing null. D depends on the hardware doing this 
(Walter has said so many times), so if C doesn't do it, then D won't. So 
those systems would have to be treated specially, and you'd have to work 
out your own home-grown mechanism for memory safety.


What Moritz is saying is that the following implementation of fclose is 
correct according to the C standard:


int fclose(FILE *stream){
if(stream == NULL){
go_wild_and_corrupt_all_the_memory();
}else{
actually_close_the_file(stream);
}
}

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) specific 
implementation detail (it's what you generally expect to happen, but 
AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D would 
not crash when dereferencing null. D depends on the hardware doing this 
(Walter has said so many times), so if C doesn't do it, then D won't. So 
those systems would have to be treated specially, and you'd have to work 
out your own home-grown mechanism for memory safety.


Optionally, one can redefine @safe *on those platforms* to say all 
dereferences will be checked against null, and then it could work on 
such platforms (and of course, you'd have to remove the @trusted marks 
from low-level C calls).


Either way, we can mark these as @trusted for all current D platforms.

-Steve

[Issue 17428] [scope] class field assignment allows to escape scope parameters

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7025

--

[Issue 17690] New: scope guards leak declarations

[via Digitalmars-d-bugs]

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

  Issue ID: 17690
   Summary: scope guards leak declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

---
void main(){
scope(exit) int x=3;
assert(x==3);
}
---
---
Internal error: ddmd/backend/symbol.c 1040
---

The problem is that the parser passes PScurlyscope instead of PSscope when
parsing the scope guard statement.

--

[Issue 17689] New: finally clause leaks declarations

[via Digitalmars-d-bugs]

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

  Issue ID: 17689
   Summary: finally clause leaks declarations
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

The following code compiles and runs:

void main(){
try{}
finally int x=3;
assert(x==3);
}

The problem is that the parser does not pass PSscope when parsing the statement
for the finally clause.

--

[Issue 17688] New: ICE with static foreach directly inside switch

[via Digitalmars-d-bugs]

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

  Issue ID: 17688
   Summary: ICE with static foreach directly inside switch
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ice, ice-on-valid-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timon.g...@gmx.ch

The following code generates an ICE:

---
void main(){
final switch(1) static foreach(x;0..1){ case 1: return; }
}
---

---
Statement::blockExit(0x7fe21d91c360)
static foreach (x; 0 .. 1)
{
case 1:
{
return ;
}
}

core.exception.AssertError@ddmd/blockexit.d(90): Assertion failure

---

The reason is that the DMD code base does not uphold some invariants I took for
granted.

--

Re: Cast to subclass in the dmd compiler

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 21:06:25 UTC, unDEFER wrote:

I have found the answer in the code.
Right code is:

Import imp = m.isImport();
if (imp !is null)

Thank you.


grep for kluge in code, you'll find all the places it does its 
own RTTI.

[Issue 17685] DMD 2.060 regression: align is not respected for structs

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[Sönke Ludwig via Digitalmars-d]

Am 25.07.2017 um 20:47 schrieb ciechowoj:

As Jacob Carlborg said it's for the dstep.

On Tuesday, 25 July 2017 at 15:18:04 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
What's wrong with the current error message? Doesn't it do that?


Nope, this message looks like intended for the library author rather
than for a library user.

What I want is a message that signals that the compilation isn't
possible with the default x86 arch and the user has to use x86_mscoff arch.


That's precisely what --arch (or simply -a) is for. But you can avoid
passing it explicitly by setting the $DUB_ARCH environment variable
(as per the dub documentation).


To disable the warning I mentioned in the first post I needed to remove
the `-m32mscoff` flag. Now the library can be compiled only with
explicit specification of the architecture.

However the default arch is what the library's end user will select most
likely.
And then they will receive unhelpful message about OPTLINK being unable
to parse the VS linker command line.

Ideally I would like to be able to suppress m32mscoff warning and build
for x86_mscoff by default (or amd64).

Setting $DUB_ARCH is unacceptable as well.




What you can do is to create a configuration that only works for x86_64:

name "myproject"

configuration "library" {
platforms "x86_64"
targetType "library"
// ...
}

This will cause the configuration resolution to fail if the wrong 
architecture is selected. The downside is that I think the error message 
will not be very helpful currently (something like "could not resolve 
configuration for myproject"), but that should be fixable.

Re: Crypto.lib and ssl.lib for Win32

[Adam D. Ruppe via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 12:11:08 UTC, MGW wrote:
Where can I find the ready made for usage or how to create 
cryptro.lib and ssl.lib for Windows 32 that are necessary for 
my project?


Do you have the crypto.dll and ssl.dll? If so, implib can make 
the lib files. If you don't have implib, email the dlls to me and 
I'll get it to you (destructiona...@gmail.com)

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer 
wrote:

On 7/25/17 2:36 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer 
wrote:

On 7/25/17 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047




Looks fine to me. That's not an array of FILE, it's a single 
pointer.


fgetc cannot be @trusted the same way fclose cannot be 
@trusted.
If you pass either of them `null` - which constitutes a legal 
@safe context - the behaviour is undefined, which contradicts 
@trusted definition:
exhibit any undefined behavior if called by a safe function.>


The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) 
specific implementation detail (it's what you generally expect to 
happen, but AFAIK it isn't defined in official ISO/IEC C).


This is par for the course in @safe land -- dereferencing null 
pointers  is OK.


In D land we require null dereferences to crash.

That means - from a strict, pedantic standpoint - that while it's 
OK to attribute D functions with null dereferences as @trusted, 
the same can't be said for C functions with null dereferences.

[your code here] Pure RPN calculator

[Max Haughton via Digitalmars-d]

Semi-Functional/pure RPN calculator: 
https://run.dlang.io/is/JGkBZx


This is probably too long, but it demonstrates the compiler 
enforced safety and purity (State is passed through the fold), 
while also showing off the higher level parts of Phobos (Use of 
fold).

[Issue 17687] New: Ddoc: Automatically highlight class names

[via Digitalmars-d-bugs]

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

  Issue ID: 17687
   Summary: Ddoc: Automatically highlight class names
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: wolfr...@protonmail.com

When building the docs, dmd automatically highlights the names of function
parameters, if not prefixed with an underscore. This is not currently done for
class names, when referencing the enclosing class in the documentation of a
member function.

See also https://dlang.org/phobos/std_file.html#.DirEntry for example, where
this would solve an inconsistency.

--

Re: Cast to subclass in the dmd compiler

[unDEFER via Digitalmars-d-learn]

I have found the answer in the code.
Right code is:

Import imp = m.isImport();
if (imp !is null)

Thank you.

Re: Cast to subclass in the dmd compiler

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/25/17 4:36 PM, unDEFER wrote:

Hello!
I'm hacking dmd compiler and trying to look on members array just after 
parse module.


for(uint i = 0; i < members.dim; i++)
{
  Dsymbol m = (*members)[i];

// It is good, but further:

 Import imp = cast(Import) m;
 if (imp !is null)
 {
 printf(" import %s.%s\n", imp.packages.toChars(), 
imp.id.toChars());

 }
// ...
}

For really imports casting doing well. But for not imports it again 
casts, imp not is null and  the compiler crashes.

What I'm doing wrong?


I think it's likely that these are actually C++ classes, and probably 
there is no RTTI, so this is a reinterpret cast. This is a wild guess, 
but much of the compiler still needs to interface with C++ backend.


I would look elsewhere in the compiler to see how they handle this type 
of thing. Not sure of dynamic_cast support?


-Steve

[Issue 17568] [scope] addresses to fields can be escaped from scope method

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7022

--

[Issue 6004] std.range.unzip()

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--

Cast to subclass in the dmd compiler

[unDEFER via Digitalmars-d-learn]

Hello!
I'm hacking dmd compiler and trying to look on members array just 
after parse module.


for(uint i = 0; i < members.dim; i++)
{
 Dsymbol m = (*members)[i];

// It is good, but further:

Import imp = cast(Import) m;
if (imp !is null)
{
printf(" import %s.%s\n", imp.packages.toChars(), 
imp.id.toChars());

}
// ...
}

For really imports casting doing well. But for not imports it 
again casts, imp not is null and  the compiler crashes.

What I'm doing wrong?

[Issue 6004] std.range.unzip()

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrei Alexandrescu  ---
(In reply to Seb from comment #5)
> > For forward ranges of tuples "unzip" can be implemented in a few lines. E.g.
> 
> That's pretty sweet! I actually built something on top of this and was about
> to submit it:
> 
> https://github.com/dlang/phobos/compare/master...wilzbach:unzip
> 
> But then I realized that std.range.transversal already solves this nicely:
> 
> import std.algorithm, std.range, std.stdio;
> int[][] x = new int[][3];
> x[0] = [1, 2, 3];
> x[1] = [4, 5, 6];
> x.transversal(1).writeln; // [2, 5]
> x.front.walkLength.iota.map!(i => transversal(x, i)).writeln; // [[1, 4],
> [2, 5], [3, 6]]
> 
> Plat with this online: https://is.gd/YYCgPk
> 
> So I'm inclined to close this as WORKSFORME - other opionions?

Seb, could you please copy the example you wrote in transversal? Also mention
the feature can be found in other languages with the name "unzip", thus making
the term searchable. It would close this bug. Thanks!

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 2:36 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer wrote:

On 7/25/17 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047 



Looks fine to me. That's not an array of FILE, it's a single pointer.


fgetc cannot be @trusted the same way fclose cannot be @trusted.
If you pass either of them `null` - which constitutes a legal @safe 
context - the behaviour is undefined, which contradicts @trusted 
definition:
undefined behavior if called by a safe function.>


The behavior is defined. It will crash with a segfault. This is par for 
the course in @safe land -- dereferencing null pointers is OK.


What is not defined is to fclose a file, and then use that FILE * in any 
way afterwards without reassigning.


Note that @safe functions don't make any guarantees once you pass in an 
invalid (except for null) or dangling pointer. However, if you are using 
only @safe code, you shouldn't be able to make one of these either. 
Hence fclose is not @safe or @trusted.


The one case where this fails is for a null pointer to a very very large 
struct that has a way to reference data outside the protected page. I 
have proposed in the past a way to protect against this, but it didn't 
gain any traction.


-Steve

Re: Problem while copy Array Element to variable

[Zaheer Ahmed via Digitalmars-d]

On Tuesday, 25 July 2017 at 17:11:37 UTC, Ali Çehreli wrote:

On 07/25/2017 09:14 AM, Zaheer Ahmed wrote:
> My Dynamic array completely work good but when assign it's
one index to
> a variable, it's saves ASCII of that index.
> writeln(myarray); // output 24
> var = myarray[0]; // it assign 50 to var
> Why changed to ASCII and how to get rid of.

First, just to remind you that this question would be more 
helpful on the Learn forum. :)


You're not showing any code so I try to reproduce the issue:

import std.stdio;

void main() {
auto myarray = "24";
writeln(myarray); // output 24
int var;
auto var = myarray[0]; // it assign 50 to var
writeln(var);
}

myarray[0] has the value 50 because 50 is the ASCII code of '2'.

The reason var gets 50 in the above scenario is because var is 
an int. If you want to get char '2' (of course still with the 
value 50), you can make it char:


   char var;

On the other hand, if you want to get the integer value 2, 
there is the trick of subtracting the value of '0' from it:


var = myarray[0] - '0';

var now has value 2.

Ali


I got this with var = myarray[0] - '0'; without this I have to 
manually pollute my code.

Thanks for Solution & also for writing Book on D Lang.

Re: unittest-cov - results?

[0xEAB via Digitalmars-d-learn]

On Wednesday, 5 July 2017 at 19:13:21 UTC, Jolly James wrote:
On Wednesday, 5 July 2017 at 19:01:06 UTC, Jonathan M Davis 
wrote:
On Wednesday, July 05, 2017 18:50:32 Jolly James via 
Digitalmars-d-learn wrote:

On Wednesday, 5 July 2017 at 18:46:38 UTC, Jolly James wrote:
> [...]

I have changed the 'build' to 'test' in the command. Now at 
least I get the following message: "All unit tests have been 
run successfully." which should not actually happen, as my 
code contains an 'assert(false);' unittest.


If you don't run the tests, you won't get any code coverage. 
Building with


dub test --coverage


The following command does not change anything:
  dub test --coverage --arch=x86_64 --compiler=ldc2
All I get is "All unit tests have been run successfully." in 
the command line.



should do it. As for your assert(false) test failing, was it 
in the same module with your main in it?


No, this test is actually in module 'tools.array'.


Hello,

I faced a similar issue today. In my case the utests weren't run 
because they were part of a templated class. They don't get 
executed in such a case because a valid utest mustn't be 
templated.

Re: An Issue I Wish To Raise Awareness On

[Marco Leise via Digitalmars-d]

Am Thu, 20 Jul 2017 08:56:57 +
schrieb Kagamin :

> On Wednesday, 19 July 2017 at 12:56:38 UTC, Marco Leise wrote:
> > That's exactly what I was opposing in the other post. These
> > handles are opaque and never change their value. Within the
> > Dlang language barrier they can be immutable and as such,
> > implicitly shared.  
> 
> Given transitivity of immutability the handle should have the 
> same immutability as the resource it represents.

I understand that you apply D keywords to C types in a
best fit fashion, to get some errors from the compiler when
you use them in the wrong context. It should work alright in
some APIs (maybe you can show me an example).

But since C does not have these qualifiers, one function may
be used for shared and unshared resources or the library may
even be compiled with or without thread-safety enabled and you
have to query that at *runtime*, where you have no help from
the type-system. So I believe, relying on the pattern will be
frustrating at times as not general enough.

What I seek to achieve by slapping immutable on things like
file descriptors and opaque types is the use as hash table
keys. As the hashed part of hash table keys must not change,
this approach enables us to use these types as keys and
statically verify immutability, too.

Because opaque structs and integer handles are used in C
APIs to *hide* the implementation details, the compiler is
deliberately left blind. That FILE* could as well be an
integer as far as transitivity of `immutable` goes. Nothing
the compiler *can see of it* will ever change. And that's all
the type system will ever care about really! Even if part of
that hidden structure is actually returned mutably by some
function, it is just an implementation detail. Whether you
slap `immutable` on anything there is mostly cosmetic.

Now what does that mean for type checks in practice?

1) Looking at POSIX' C `fgetc()` function, the stream is a
   plain FILE*: int fgetc (FILE *stream).
   Since I/O is thread-safe[1], it should ideally be `shared`
   the way you put it. And the way I look at it, it should be
   `immutable` on *our* side of the language barrier. (I.e.
   Dlang wont be able to change its contents or see the
   contents change.)

2) You can look up items by file descriptors or FILE* in hash
   tables implementations with immutable keys.

So we can take this away:
* Making a struct opaque, is implicitly making it immutable,
  because it's contents cannot be modified nor read directly - 
  the compiler cannot reason about its contents.
* Now we also have a layman's head-const, making resource
  pointers usable as immutable hash table keys.

As you can see my thinking revolves around the idea that hash
table keys must be immutable and that stems from the idea that
once hashed and sorted into a table, the hashed data must not
change. There are other approaches and druntime's AAs simply
allow mutable keys:

void main() {
struct S { int* i; }
int a = 1, b = 2;
uint[S] aa;
aa[S()] = 42;
foreach(ref s_key; aa.byKey())
// Allows "innocent" changes to the keys
s_key.i = 
foreach(ref s_key; aa.byKey())
// AA doesn't find the key it just returned! Range 
violation.
uint u = aa[s_key];
}

-- 
Marco

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[ciechowoj via Digitalmars-d]

As Jacob Carlborg said it's for the dstep.

On Tuesday, 25 July 2017 at 15:18:04 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
What's wrong with the current error message? Doesn't it do that?


Nope, this message looks like intended for the library author 
rather than for a library user.


What I want is a message that signals that the compilation isn't 
possible with the default x86 arch and the user has to use 
x86_mscoff arch.


That's precisely what --arch (or simply -a) is for. But you can 
avoid passing it explicitly by setting the $DUB_ARCH 
environment variable (as per the dub documentation).


To disable the warning I mentioned in the first post I needed to 
remove the `-m32mscoff` flag. Now the library can be compiled 
only with explicit specification of the architecture.


However the default arch is what the library's end user will 
select most likely.
And then they will receive unhelpful message about OPTLINK being 
unable to parse the VS linker command line.


Ideally I would like to be able to suppress m32mscoff warning and 
build for x86_mscoff by default (or amd64).


Setting $DUB_ARCH is unacceptable as well.

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 18:07:06 UTC, Steven Schveighoffer 
wrote:

On 7/25/17 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047


Looks fine to me. That's not an array of FILE, it's a single 
pointer.


fgetc cannot be @trusted the same way fclose cannot be @trusted.
If you pass either of them `null` - which constitutes a legal 
@safe context - the behaviour is undefined, which contradicts 
@trusted definition:
exhibit any undefined behavior if called by a safe function.>

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/25/2017 02:20 PM, Steven Schveighoffer wrote:

On 7/25/17 2:14 PM, Andrei Alexandrescu wrote:

On 07/25/2017 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047 



That might be a mistake. Is fclose(f); getc(f); defined? -- Andrei


fclose is not @safe.


Ah, nice. Thanks! -- Andrei

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 2:14 PM, Andrei Alexandrescu wrote:

On 07/25/2017 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047


That might be a mistake. Is fclose(f); getc(f); defined? -- Andrei


fclose is not @safe.

The charter of @safe (or @trusted in this case) is to assume valid 
pointers for parameters.


-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/25/2017 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047


That might be a mistake. Is fclose(f); getc(f); defined? -- Andrei

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/25/2017 11:50 AM, Steven Schveighoffer wrote:

On 7/25/17 11:26 AM, Andrei Alexandrescu wrote:


About http://man7.org/linux/man-pages/man2/read.2.html, there's just a 
bit of wrapping necessary:


nothrow @trusted @nogc
ssize_t read(int fd, ubyte[] buf)
{
 return read(fd, buf.ptr, buf.length);
}

(btw void[] doesn't work)


[snip]

A suite of safe wrappers on OS primitives might be useful.


Great idea! Should it be a package on its own, or should we put the 
wrappers inside the original files?


That is, do we make

core.sys.safe.posix.unistd: read

or do we make

core.sys.posix.unistd: safe_read

?

My preference is for the former, since it's very nice to have a pristine 
copy of the header file.


Same here. I'd preserve the function name though. -- Andrei

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 12:46 PM, Kagamin wrote:

On Tuesday, 25 July 2017 at 15:12:30 UTC, Steven Schveighoffer wrote:
I think signalfd can be marked @trusted, as @safe code supports 
pointing at a single element.


What about functions that take zero terminated strings? Are they ok to 
read past the end of allocated object?


No, a null terminated string is as arbitrary as passing in a length.

Unfortunately, it's perfectly safe to call with a string literal. But 
there is no way to detect that during compile time. So it has to be unsafe.


The wrapper would be to use toStringz to make the call.

-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 12:14 PM, Kagamin wrote:
While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047


Looks fine to me. That's not an array of FILE, it's a single pointer.

-Steve

Re: GtkD on android?

[Joakim via Digitalmars-d-learn]

On Saturday, 22 July 2017 at 18:59:44 UTC, FoxyBrown wrote:
With LDC's new ability to do android/arm, we are missing the 
ability to do GUI's? Can any of the current D solutions work 
such as GtkD or QtD? I'm looking for something somewhat 
lightweight, easy to use(I find GtkD a bit funky but it does 
seem to work and is relatively easy once one gets through the 
basics). I think having a GUI builder is crucial though as it 
makes it so much easier in the long run. Glade is a bit funky 
but functional and works.


Ideally I'd like to be able to make portable apps that just 
work across the board(mac, linux, windows, android) without 
much hassle.


Mike said maybe later, when I asked him in January:

http://forum.dlang.org/post/o4rq0i$dur$1...@digitalmars.com

In the meantime, you can try DlangUI, as Seb pointed out, but I 
get the impression it's not touch-optimized, just like Gtk.

Re: Prevent destroy() from calling base deconstructor of a derived class?

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 17:50:18 UTC, Dragonson wrote:
I need to call only the deconstructor of the derived class I 
have an instance of, not every deconstructor in the inheritance 
chain. Putting `override` before the destructor doesn't compile 
so I'm not sure how to achieve this?


Call the finalizer directly:

---
import std.stdio;
import std.experimental.allocator;
import std.experimental.allocator.mallocator;

class A
{
~this()
{
writeln("A.~this");
}
}

class B : A
{
~this()
{
writeln("B.~this");
}
}

void main()
{
B b = Mallocator.instance.make!B;
b.__dtor();
}
---

You're violating how inheritance is designed to work, though, so 
this will leave the object in an alive state (the finalizer may 
be called a second time on manual destroy call or GC 
finalization, at which point the parent class' finalizer will 
still be called).

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[Jacob Carlborg via Digitalmars-d]

On 2017-07-25 17:18, Mike Parker wrote:

That's precisely what --arch (or simply -a) is for. But you can avoid 
passing it explicitly by setting the $DUB_ARCH environment variable (as 
per the dub documentation).


The use case is for DStep which requires to link with the Microsoft tool 
chain since the Clang libraries are only available in the COFF format. 
To make it as convenient as possible it would be nice to be able to 
specify in the dub.json without getting warnings.


--
/Jacob Carlborg

Prevent destroy() from calling base deconstructor of a derived class?

[Dragonson via Digitalmars-d-learn]

I need to call only the deconstructor of the derived class I have 
an instance of, not every deconstructor in the inheritance chain. 
Putting `override` before the destructor doesn't compile so I'm 
not sure how to achieve this?

Re: Why structs and classes instanciations are made differently ?

[Kagamin via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 15:56:45 UTC, Houdini wrote:
Yes, but it isn't the default way in C++ to do dynamic 
instanciation.


https://github.com/isocpp/CppCoreGuidelines this? It's only 2 
years old. The new operator predates it by decades.

Re: Problem while copy Array Element to variable

[Ali Çehreli via Digitalmars-d]

On 07/25/2017 10:11 AM, Ali Çehreli wrote:


int var;
auto var = myarray[0]; // it assign 50 to var


Remove that 'auto' please. Apparently, I edited my message instead of 
code. :p


Ali

Re: Problem while copy Array Element to variable

[Ali Çehreli via Digitalmars-d]

On 07/25/2017 09:14 AM, Zaheer Ahmed wrote:
> My Dynamic array completely work good but when assign it's one index to
> a variable, it's saves ASCII of that index.
> writeln(myarray); // output 24
> var = myarray[0]; // it assign 50 to var
> Why changed to ASCII and how to get rid of.

First, just to remind you that this question would be more helpful on 
the Learn forum. :)


You're not showing any code so I try to reproduce the issue:

import std.stdio;

void main() {
auto myarray = "24";
writeln(myarray); // output 24
int var;
auto var = myarray[0]; // it assign 50 to var
writeln(var);
}

myarray[0] has the value 50 because 50 is the ASCII code of '2'.

The reason var gets 50 in the above scenario is because var is an int. 
If you want to get char '2' (of course still with the value 50), you can 
make it char:


   char var;

On the other hand, if you want to get the integer value 2, there is the 
trick of subtracting the value of '0' from it:


var = myarray[0] - '0';

var now has value 2.

Ali

Re: all OS functions should be "nothrow @trusted @nogc"

[Kagamin via Digitalmars-d]

On Tuesday, 25 July 2017 at 15:12:30 UTC, Steven Schveighoffer 
wrote:
I think signalfd can be marked @trusted, as @safe code supports 
pointing at a single element.


What about functions that take zero terminated strings? Are they 
ok to read past the end of allocated object?

[Issue 17686] [REG2.075] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

Summary|Covariant return types  |[REG2.075] Covariant return
   |doesn't work with override  |types doesn't work with
   |in some cases   |override in some cases

--

[Issue 17686] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
To be exact it worked from 2.066 to 2.074.1:

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

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Kagamin via Digitalmars-d]

While we're at it, check this: 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L1047

Problem while copy Array Element to variable

[Zaheer Ahmed via Digitalmars-d]

My Dynamic array completely work good but when assign it's one 
index to a variable, it's saves ASCII of that index.

writeln(myarray); // output 24
var = myarray[0]; // it assign 50 to var
Why changed to ASCII and how to get rid of.

[Issue 17686] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

URL|https://run.dlang.io/is/0ho |https://run.dlang.io/is/0ho
   |AtP |AtP
   |https://code.dlang.org/pack |
   |ages/std-experimental-xml   |

--

[Issue 17686] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

URL|https://run.dlang.io/is/0ho |https://run.dlang.io/is/0ho
   |AtP |AtP
   ||https://code.dlang.org/pack
   ||ages/std-experimental-xml

--

[Issue 17686] Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

URL||https://run.dlang.io/is/0ho
   ||AtP

--

[Issue 17686] New: Covariant return types doesn't work with override in some cases

[via Digitalmars-d-bugs]

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

  Issue ID: 17686
   Summary: Covariant return types doesn't work with override in
some cases
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kozz...@gmail.com

This works before dmd 2.075

https://run.dlang.io/is/0hoAtP

this affect std_experimental_xml dub package

--

Re: Why structs and classes instanciations are made differently ?

[Houdini via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 15:15:59 UTC, Kagamin wrote:

C++ is big, there's always something you don't know about it. 
Java actually instantiates classes the C++ way: 
http://en.cppreference.com/w/cpp/language/new


Yes, but it isn't the default way in C++ to do dynamic 
instanciation. Usually, you do static initialization, except when 
the situation make taht impossible.

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 11:26 AM, Andrei Alexandrescu wrote:


About http://man7.org/linux/man-pages/man2/read.2.html, there's just a 
bit of wrapping necessary:


nothrow @trusted @nogc
ssize_t read(int fd, ubyte[] buf)
{
 return read(fd, buf.ptr, buf.length);
}

(btw void[] doesn't work)


[snip]

A suite of safe wrappers on OS primitives might be useful.


Great idea! Should it be a package on its own, or should we put the 
wrappers inside the original files?


That is, do we make

core.sys.safe.posix.unistd: read

or do we make

core.sys.posix.unistd: safe_read

?

My preference is for the former, since it's very nice to have a pristine 
copy of the header file.


-Steve

Re: H2 2017 Vision Document

[Seb via Digitalmars-d-announce]

On Tuesday, 25 July 2017 at 14:16:18 UTC, Atila Neves wrote:
"We have added merge rights to three contributors and are 
looking for more"


How would one go about volunteering?

Atila


Btw we have introduced a CODEOWNERS file at Phobos two weeks ago 
(druntime and dmd will come soon as well).
This means that if someone knows/cares about a module at Phobos, 
it's just a trivial PR away to get involved:


https://github.com/dlang/phobos/blob/master/CODEOWNERS

NB: For the CODEOWNERS feature one doesn't even need to be part 
of "Team Phobos".

Re: VibeD - takeing out value from json

[holo via Digitalmars-d-learn]

There was need to change one line from:

auto header = result["heading"].to!string;

to:

auto header = result[0]["heading"].to!string;

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 14:39:15 UTC, Shachar Shemesh wrote:

On 25/07/17 17:24, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh 
wrote:

The title really does says it all.


Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and 
they should be nothrow, anyway).
Technically, any system call that is a pthreads cancellation 
point may throw a C++ exception.


Good to know, then since D is supposed to be able to catch C++ 
exceptions (and can on 64bit Linux [1]) none of those may be 
attributed as `nothrow`, because C++ exceptions don't derive from 
`Error`.




If we go down that route, however, calling system calls from 
nothrow becomes completely impossible, which is another way of 
saying that decorating just about anything with nothrow becomes 
impossible.


No. `nothrow` functions can call throwing ones, as long as they 
catch any exceptions not derived from Error thrown by them.




@trusted: This can only be done for those functions that don't 
take arguments open to memory corruption. Take a look at POSIX 
read, it can never be trusted (same as any C function taking 
pointer+length of pointed to).
@nogc: This can only be done for those functions that are 
statically known to never call a D callback that's not also 
@nogc. Take a look at pthread_create vor pthread_join, they 
can never be @nogc, because that would mean threads may never 
allocate with the GC.


The decoration's situation with callbacks is pretty horrible 
throughout D.


Do you mean throughout druntime and phobos?

I'm not sure this is the most compelling argument, however. The 
function passed to pthread_create does not, logically, run in 
the pthread_create function. As such, I don't think this logic 
holds.


Then the @nogc definition would need to be updated from: "or 
indirectly through functions it may call" to reflect this, 
because that can be interpreted both ways.




As for pthread_join, I have no idea what you meant by it. 
Please elaborate why you think it is a problem.


Possible scenario on single core (no hyperthreading) system:
- thread 1 spawns thread 2
- thread 1 enters @nogc function `foo` and calls `pthread_join` 
on thread 2 before its own timeslice is over (and thus enters 
blocked state)

- thread 2 does work allocating via the GC, then terminates
- thread 1 wakes up and leaves @nogc function `foo`

Because @nogc (in contrast to nothrow) is explicitly designed as 
transitive, logically speaking, `foo` violated its @nogc 
constraint (it *caused* the GC allocations in thread 2).






---
auto result = () @trusted { return systemFunction(...) }();
---


Care to explain how to adapt that neat trick for "nothrow" and 
"@nogc"?


nothrow: assumeWontThrow [2]
@nogc: assumeNoGC [3]

[1] http://forum.dlang.org/thread/n7jorc$1ied$1...@digitalmars.com
[2] https://dlang.org/library/std/exception/assume_wont_throw.html
[3] https://p0nce.github.io/d-idioms/#Bypassing-@nogc

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/25/2017 10:43 AM, ag0aep6g wrote:

On 07/25/2017 04:32 PM, Shachar Shemesh wrote:
And, indeed, the code calling "read" shouldn't be able to do that as 
@safe. Read itself, however, is trusted (because, let's face it, if 
you cannot trust the kernel, you're screwed anyways).


That's not how `@trusted` works. The point of `@trusted` is to allow 
unsafe features in the implementation. The interface must be just as 
safe as with `@safe`.


`read` doesn't have a safe interface. `read` is safe as long as long as 
you pass good arguments. When you pass bad arguments, `read` will break 
your stuff. A `@trusted` function must always be safe, no matter the 
arguments.


About http://man7.org/linux/man-pages/man2/read.2.html, there's just a 
bit of wrapping necessary:


nothrow @trusted @nogc
ssize_t read(int fd, ubyte[] buf)
{
return read(fd, buf.ptr, buf.length);
}

(btw void[] doesn't work)

The point being that a safe D program needs to guarantee memory will not 
be corrupted, and there's no way for the type system to ensure that in 
the Posix read() call the buffer and the length are coordinated.


Certain systems (such as the static checker used at Microsoft - it's 
fairly well known, there are a couple of papers on it, forgot the name) 
require annotations in the function signature to indicate the 
coordination, e.g.:


ssize_t read(int fd, void *buf, @islengthof(buf) size_t count);

Then the type checker can verify upon each call that indeed count is the 
right size of buf.


A suite of safe wrappers on OS primitives might be useful.


Andrei

Re: H2 2017 Vision Document

[Andrei Alexandrescu via Digitalmars-d-announce]

On Tuesday, 25 July 2017 at 15:09:37 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 14:16:18 UTC, Atila Neves wrote:



How would one go about volunteering?

Atila


I think you just did.


Atila, welcome to Team Phobos.

Re: Is there a way to use x86 and x86_mscoff with dub simultaneously.

[Mike Parker via Digitalmars-d]

On Tuesday, 25 July 2017 at 14:17:54 UTC, ciechowoj wrote:
Currently dub reports following message when the -m32mscoff 
flag is specified in dub.json.



```
-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to 
specify the target architecture, e.g. 'dub build --arch=x86_64'


architecture explicitly or at least provide a meaningful 
message to the user that they should use `--arch=x86_mscoff` ?


What's wrong with the current error message? Doesn't it do that?



Or a way to force dub to use VS linker instead of OPTLINK for 
x86 case?

Or a way to override the default architecture?


That's precisely what --arch (or simply -a) is for. But you can 
avoid passing it explicitly by setting the $DUB_ARCH environment 
variable (as per the dub documentation).

Re: Why structs and classes instanciations are made differently ?

[Kagamin via Digitalmars-d-learn]

On Monday, 24 July 2017 at 15:21:54 UTC, Houdini wrote:
D is very similar to C++ (and also grabs godd ideas from 
Python), but I have a naive question : why does Walter Bright 
chose to instanciate classes like in Java ?


C++ is big, there's always something you don't know about it. 
Java actually instantiates classes the C++ way: 
http://en.cppreference.com/w/cpp/language/new

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/25/17 10:27 AM, Shachar Shemesh wrote:

On 25/07/17 17:12, Stefan Koch wrote:

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes to 
them. Otherwise I simply cannot call "signalfd" and "sigemptyset" (to 
name a couple from my most recent history) from @safe code.


I can try and set up a PR when I have the time. If anyone else wants 
to take an easy one before then, you're welcome to :-)


Shachar


these functions are supposed to have trused wrappers if used in safe 
code.


I'd love to hear the difference between:
extern(C) int signalfd (int __fd, const(sigset_t)* __mask, int __flags) 
nothrow @nogc;


and
int signalfdWrapper(int __fd, const(sigset_t)* __mask, int __flags) 
nothrow @trusted @nogc {

 return signalfd(__fd, __mask, __flags);
}


I think signalfd can be marked @trusted, as @safe code supports pointing 
at a single element.


Other system calls that accept a pointer/length combo cannot be marked 
@trusted.


-Steve

Re: H2 2017 Vision Document

[Mike Parker via Digitalmars-d-announce]

On Tuesday, 25 July 2017 at 14:16:18 UTC, Atila Neves wrote:



How would one go about volunteering?

Atila


I think you just did.

Re: unittest blocks not being run inside of class and struct templates

[Kagamin via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 02:48:57 UTC, NoBigDeal256 wrote:
What is the standard way of testing class templates in the 
context of a library where some of the classes may never 
actually be used by the library itself?


Write a test and instantiate whatever templates you want to test.

class Test(T) {
}

unittest {
auto t=new Test!int;
assert(t.method1()==1);
}

[Issue 17685] DMD 2.060 regression: align is not respected for structs

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
> Have you checked with 2.075.0? Works for me.

Yep, verified with DReg:

https://run.dlang.io/gist/4624d3499159997d2f90466bd7409967?compiler=dreg

This is Vladimir's tool to run a file against multiple compilers and comparing
the output. At the moment run.dlang.io runs 2.060.0 and upwards.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 14:32:18 UTC, Shachar Shemesh wrote:

On 25/07/17 17:11, ag0aep6g wrote:

On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes 
to them. Otherwise I simply cannot call "signalfd" and 
"sigemptyset" (to name a couple from my most recent history) 
from @safe code.


Not all OS functions can be `@trusted`.

I don't about `signalfd` and `sigemptyset`, but `read` [1] 
can't be `@trusted`, for example. It takes pointer and length 
separately, and the pointer is a `void*`. That's not safe at 
all.


And, indeed, the code calling "read" shouldn't be able to do 
that as @safe. Read itself, however, is trusted


No, it is not, because it does not fulfill the definition of 
@trusted (callable from *any* @safe context without allowing 
memory corruption).


(because, let's face it, if you cannot trust the kernel, you're 
screwed anyways).


This has nothing to do with trusting the kernel:
---
char[1] buf;
int dontCorruptMePlease;
read(fd, [0], 10);
---
The read implementation can't verify the buffer size, it must 
assume it to be correct. If it's too large  for the actual buffer 
-> memory corruption.
No function taking pointer+size of pointed to (that accesses 
them) can be @trusted.


Having said that, I have no objection to excluding the 
"pointer+length" system calls from the above rule. They are, by 
far, the minority of system calls.


And also happen to be the most used ones.
But I digress, the point is *every single functionust be verified 
for every single Attribute* (other than nothrow).

PRs are welcome :)

Re: all OS functions should be "nothrow @trusted @nogc"

[ag0aep6g via Digitalmars-d]

On 07/25/2017 04:32 PM, Shachar Shemesh wrote:
And, indeed, the code calling "read" shouldn't be able to do that as 
@safe. Read itself, however, is trusted (because, let's face it, if you 
cannot trust the kernel, you're screwed anyways).


That's not how `@trusted` works. The point of `@trusted` is to allow 
unsafe features in the implementation. The interface must be just as 
safe as with `@safe`.


`read` doesn't have a safe interface. `read` is safe as long as long as 
you pass good arguments. When you pass bad arguments, `read` will break 
your stuff. A `@trusted` function must always be safe, no matter the 
arguments.

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 25/07/17 17:24, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:

The title really does says it all.


Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and they should 
be nothrow, anyway).
Technically, any system call that is a pthreads cancellation point may 
throw a C++ exception.


If we go down that route, however, calling system calls from nothrow 
becomes completely impossible, which is another way of saying that 
decorating just about anything with nothrow becomes impossible.


@trusted: This can only be done for those functions that don't take 
arguments open to memory corruption. Take a look at POSIX read, it can 
never be trusted (same as any C function taking pointer+length of 
pointed to).
@nogc: This can only be done for those functions that are statically 
known to never call a D callback that's not also @nogc. Take a look at 
pthread_create vor pthread_join, they can never be @nogc, because that 
would mean threads may never allocate with the GC.


The decoration's situation with callbacks is pretty horrible throughout 
D. I'm not sure this is the most compelling argument, however. The 
function passed to pthread_create does not, logically, run in the 
pthread_create function. As such, I don't think this logic holds.


As for pthread_join, I have no idea what you meant by it. Please 
elaborate why you think it is a problem.




---
auto result = () @trusted { return systemFunction(...) }();
---


Care to explain how to adapt that neat trick for "nothrow" and "@nogc"?

Shachar

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 25/07/17 17:11, ag0aep6g wrote:

On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes to them. 
Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a 
couple from my most recent history) from @safe code.


Not all OS functions can be `@trusted`.

I don't about `signalfd` and `sigemptyset`, but `read` [1] can't be 
`@trusted`, for example. It takes pointer and length separately, and the 
pointer is a `void*`. That's not safe at all.


And, indeed, the code calling "read" shouldn't be able to do that as 
@safe. Read itself, however, is trusted (because, let's face it, if you 
cannot trust the kernel, you're screwed anyways).


Having said that, I have no objection to excluding the "pointer+length" 
system calls from the above rule. They are, by far, the minority of 
system calls.


Shachar

[Issue 17685] DMD 2.060 regression: align is not respected for structs

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Have you checked with 2.075.0? Works for me.

--

Re: all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

On 25/07/17 17:12, Stefan Koch wrote:

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes to them. 
Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a 
couple from my most recent history) from @safe code.


I can try and set up a PR when I have the time. If anyone else wants 
to take an easy one before then, you're welcome to :-)


Shachar


these functions are supposed to have trused wrappers if used in safe code.


I'd love to hear the difference between:
extern(C) int signalfd (int __fd, const(sigset_t)* __mask, int __flags) 
nothrow @nogc;


and
int signalfdWrapper(int __fd, const(sigset_t)* __mask, int __flags) 
nothrow @trusted @nogc {

return signalfd(__fd, __mask, __flags);
}

Or are you suggesting the wrapper do something else?

Shachar

Re: all OS functions should be "nothrow @trusted @nogc"

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:

The title really does says it all.


Since you explicitly state *all* OS functions:
nothrow: Should be OK (only callbacks could violate this and they 
should be nothrow, anyway).
@trusted: This can only be done for those functions that don't 
take arguments open to memory corruption. Take a look at POSIX 
read, it can never be trusted (same as any C function taking 
pointer+length of pointed to).
@nogc: This can only be done for those functions that are 
statically known to never call a D callback that's not also 
@nogc. Take a look at pthread_create vor pthread_join, they can 
never be @nogc, because that would mean threads may never 
allocate with the GC.


I keep copying OS function declarations into my code, just so I 
can add those attributes to them. Otherwise I simply cannot 
call "signalfd" and "sigemptyset" (to name a couple from my 
most recent history) from @safe code.


---
auto result = () @trusted { return systemFunction(...) }();
---

Re: H2 2017 Vision Document

[Atila Neves via Digitalmars-d-announce]

On Monday, 24 July 2017 at 23:13:16 UTC, Mike Parker wrote:
The latest edition of the biannual vision document is now 
available at the D Wiki. Major focuses for the remainder of the 
year include improvements to @safety, @nogc, and language 
interoperability, as well as fostering increased contributions.


https://wiki.dlang.org/Vision/2017H2


"We have added merge rights to three contributors and are looking 
for more"


How would one go about volunteering?

Atila

Is there a way to use x86 and x86_mscoff with dub simultaneously.

[ciechowoj via Digitalmars-d]

Currently dub reports following message when the -m32mscoff flag 
is specified in dub.json.



```
-m32mscoff: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to 
specify the target architecture, e.g. 'dub build --arch=x86_64'

```

The problem is after the change the user is unable to build the 
project just with `dub build` (they need to specify the arch 
explicitly).


Is there a way to avoid the requirement for specifying the 
architecture explicitly or at least provide a meaningful message 
to the user that they should use `--arch=x86_mscoff` ?


Or a way to force dub to use VS linker instead of OPTLINK for x86 
case?

Or a way to override the default architecture?

Re: all OS functions should be "nothrow @trusted @nogc"

[Stefan Koch via Digitalmars-d]

On Tuesday, 25 July 2017 at 13:50:16 UTC, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes 
to them. Otherwise I simply cannot call "signalfd" and 
"sigemptyset" (to name a couple from my most recent history) 
from @safe code.


I can try and set up a PR when I have the time. If anyone else 
wants to take an easy one before then, you're welcome to :-)


Shachar


these functions are supposed to have trused wrappers if used in 
safe code.

Re: all OS functions should be "nothrow @trusted @nogc"

[ag0aep6g via Digitalmars-d]

On 07/25/2017 03:50 PM, Shachar Shemesh wrote:
The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes to them. 
Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a 
couple from my most recent history) from @safe code.


Not all OS functions can be `@trusted`.

I don't about `signalfd` and `sigemptyset`, but `read` [1] can't be 
`@trusted`, for example. It takes pointer and length separately, and the 
pointer is a `void*`. That's not safe at all.



[1] http://man7.org/linux/man-pages/man2/read.2.html

[Issue 17685] New: DMD 2.060 regression: align is not respected for structs

[via Digitalmars-d-bugs]

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

  Issue ID: 17685
   Summary: DMD 2.060 regression: align is not respected for
structs
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: clugd...@yahoo.com.au

Yes, I know this a regression from 5 years ago. But some of us are using
compilers from even earlier

There is a real problem with the behaviour of align().


align(1) struct A {
align(1):
   int a;
}

static assert(A.alignof == 1);  // fails, A.alignof is 4

In 2.059 and earlier (including D1), that static assert would pass.


Note that for a struct which should have the same properties:

struct B {
   ubyte[4] b;
}

static assert(B.alignof == 1);  // ok

So the padding is not because of the struct size.


The offending commit was made here, with a dreadful commit message:

https://github.com/dlang/dmd/commit/20fb83928b12af809798f3fa0247a4d5cdf80e4f

Previously in fact this would work even without the outer "align(1)" around the
struct. I am not sure what the motivation for that silent breaking language
change was, but it does not make any sense to me. It certainly introduces
opportunity for subtle, hideous bugs. It's particularly nasty when passing
structs to other languages.


At the time, there was a bug report on a similar issue which was closed as
invalid. https://issues.dlang.org/show_bug.cgi?id=8565

I suspect that was closed rather too hastily.

--

all OS functions should be "nothrow @trusted @nogc"

[Shachar Shemesh via Digitalmars-d]

The title really does says it all. I keep copying OS function 
declarations into my code, just so I can add those attributes to them. 
Otherwise I simply cannot call "signalfd" and "sigemptyset" (to name a 
couple from my most recent history) from @safe code.


I can try and set up a PR when I have the time. If anyone else wants to 
take an easy one before then, you're welcome to :-)


Shachar

[Issue 17667] regex([r".", r"[\(\{[\]\}\)]"]);

[via Digitalmars-d-bugs]

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

--- Comment #2 from Dmitry Olshansky  ---
https://github.com/dlang/phobos/pull/5656

--

Re: Problem with integral promotions

[Steven Schveighoffer via Digitalmars-d]

On 7/24/17 6:46 PM, Walter Bright wrote:

On 7/24/2017 2:07 PM, Walter Bright wrote:
Yes, I think a switch to enable the correct behavior, and a warning 
when the cases are encountered and the switch isn't thrown, is likely 
the best approach.


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


Yes, that should be workable.

I'm looking at some of the code that you have to update, and I'm 
wondering if ~ should still operate the way it does. While - on an 
unsigned is somewhat clear that you want a negative (and therefore a 
different type), ~ on an unsigned actually makes sense for the same type.


However, if C operates this way, this would be a huge trap for people 
who are porting code.


-Steve

Re: [OT] Re: strong typing for browser code [Was: D easily overlooked?]

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 25 July 2017 at 10:27:43 UTC, Russel Winder wrote:
There is little traction in a browser-focused language that 
doesn't offer a massive USP over JavaScript/ECMAScript – typing 
is the only USP over ES6 that has any chance really. Elm, 
Kotlin, Ceylon, etc. are already populating the market. I 
suspect Dart will have little hope for traction now.


Well, most languages have little hope for traction :-). Traction 
comes predominantly from specific use cases, so it all depends on 
whether Google is going to push Dart as a cross platform 
programming language with flutter.io and how it is used 
internally at Google. I think they use it for their Google Ads 
software, so I guess it currently is quite important for them.


Anyhow, my point was more that Google's actual usage and needs 
might affect where Go 2 heads if we judge by Dart has evolved 
over time. I assume that the initial design of Go and Dart was 
more based on designe aesthetics, and that actual demand will 
drive the evolution if they are used extensively internally at 
Google...

Re: Append to dynamic array that was allocated via calloc

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/25/17 8:40 AM, John Burton wrote:

I can create a "slice" using non-gc allocated memory.

 int* ptr = cast(int*)calloc(int.sizeof, 10);
 int[] data = ptr[0..10];

If I don't want a memory leak I have to call free(ptr) somewhere as it 
won't be GC collected when data or ptr go out of scope. I presume there 
is nothing wrong with doing the above, other than perhaps there being 
better ways (and the memory leak if not free'd)


If I then write this :-

 data ~= 1;

What happens? It seems to successfully append an extra value to the 
array. It appears to "work" when I try it in my compiler but I don't 
understand how. Will this be trying to write beyond the memory I calloc'ed?


What happens is the runtime detects that data is NOT pointing at an 
appendable GC-allocated block.


So it reallocates the whole block in the GC, and appends your element.

The original pointer is lost from data, and leaked (assuming you aren't 
manually freeing ptr somewhere).


I'd recommend using std.container.Array[1], which should do the right 
thing with malloc'd memory, and give you the nice operators such as ~=.


Or you have to resort to C calls for everything, if you don't want to 
deal with that.


Optionally, if you have a defined lifetime for this array in a scope, 
you can do this:


int *ptr = ...; // your calloc call
scope(exit) free(ptr); // ensure it is freed. Make SURE you don't change 
ptr inside the function.


Now you can use ~= on data, and it should still free the ptr at the end 
of the scope/function.


-Steve

[1] http://dlang.org/phobos/std_container_array.html#.Array

auto conversion to ascii

[Zaheer Ahmed via Digitalmars-d]

My Dynamic array complete show is good but when assign it's one 
index to a variable, it's saves ASCII of that index.

writeln(myarray); // output 24
var = myarray[0]; // it assign 50 to var
Why changed to ASCII and how to get rid of please...

Re: unittest blocks not being run inside of class and struct templates

[Steven Schveighoffer via Digitalmars-d-learn]

On 7/24/17 11:13 PM, NoBigDeal256 wrote:

On Tuesday, 25 July 2017 at 02:18:41 UTC, Adam D. Ruppe wrote:

On Tuesday, 25 July 2017 at 02:11:20 UTC, NoBigDeal256 wrote:
it passes when it should fail because the unittest block is never 
executed. Why is this?


Did you actually instantiate the class somewhere? A template has no 
concrete code unless created with an argument somewhere...


What if it's instantiated in another module? Right now I'm having issues 
where if I run 'dmd a.d b.d -unittest' and the class template in b.d is 
instantiated in a.d and it compiles and the tests inside my class 
template run as they should, but when using 'dub test' the tests in my 
class template don't run at all as if it isn't instantiated in a.d even 
though it is. This is the original issue that I had that prompted me to 
create this thread.


There is a whole can of worms to be dealt with if you put unit tests 
inside template classes or structs.


For instance:

struct Foo(T)
{
   T foo() { return T.init; }
   unittest
   {
   Foo!int f;
   assert(is(typeof(f.foo()) == int));
   }
}

the unit test is instantiated EVERY TIME Foo is instantiated, so if you 
have Foo!int and Foo!string both instantiated, BOTH will run this unit 
test. Obviously, there is no need to run both. And yes, user code will 
also add unit tests unwittingly to their code.


In some cases, this can be useful. If you write like this:

struct Foo(T)
{
   T foo() { return T.init; }
   unittest
   {
   Foo f; // note the lack of !
   assert(is(typeof(f.foo()) == T));
   }
}

This means that for every instantiation, the unit test is checking that 
Foo.foo returns T.


But this comes at a cost. Generally unit tests deal with concrete data, 
not abstract concepts. This means, you really only want to unit test for 
some instantiations, not all.


In phobos, I did this for RedBlackTree. It works well, in that test 
coverage is nearly complete over all integral types of elements. 
However, there are drawbacks:


1. RedBlackTree with -unittest *will* add unit tests to user modules 
(unavoidable).

2. There are some tricky mechanisms to make it work properly (see the code)
3. It comes back to bite me every once in a while, bugs are filed about 
this.


The unfortunate thing is that if you want to have non-templated unit 
tests, you have to put them outside the struct itself. This sucks for 
documented unit tests, and for tests being close to the thing being 
tested. I'd love to have a way to specify that a unit test is really 
outside the struct, but still have it written inside. I'm not sure if it 
would be accepted though.


-Steve

Re: Append to dynamic array that was allocated via calloc

[John Burton via Digitalmars-d-learn]

On Tuesday, 25 July 2017 at 13:24:36 UTC, Mike Parker wrote:

On Tuesday, 25 July 2017 at 12:40:13 UTC, John Burton wrote:

[...]


This should give you the answer:

writefln("Before: ptr = %s capacity = %s", slice.ptr, 
slice.capacity);

slice ~= 1;
writefln("After: ptr = %s capacity = %s", slice.ptr, 
slice.capacity);


It shows that before the append, the capacity is 0. That 
indicates that any append will cause a new allocation -- from 
the GC. The next writefln verifies this by showing a different 
value for ptr and a new capacity of 15.


In order for this to work, you'll need to manually manage the 
length and track the capacity yourself. If all you want is to 
allocate space for 10 ints, but not 10 actual ints, then 
something like this:


size_t capacity = 10;
int* ints = cast(int*)malloc(int.sizeof * capacity);
int[] slice = ints[0 .. 10];
slice.length = 0;
slice ~= 1;
--capacity;

Then reallocate the array when capacity reaches 0. Or just use 
std.container.array.Array which does all this for you.


Ok so it sounds like this is "safe" in that it will copy my data 
into GC memory and all work safely. I'll need to somehow keep 
track of my original memory and free it to avoid a memory leak...

(I don't plan to do any of this, but I wanted to understand)(