Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:
Pretty much the worst that happens is you accidentally use a 
member variable directly instead of using a property function 
to access it, and that's rarely a big deal. Often, it's even 
desirable.


I'll keep that argument for the status quo, and will be sure to 
put it in the DIP.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:46:18 UTC, Jonathan M Davis wrote:


If you really insist on the viewpoint that class encapsulation 
means that nothing outside of that class can access any of its 
private members, then what D does definitely breaks 
encapsulation. But having friends in C++ already provides a way 
to break that.


No. That is not true.

friend is explicately part of the declared interface.

D on the otherhand, tells you who your friends are.

Your interface doesn't have a say in it anymore.

When your declared interface is moot, your enscapsulation is also 
moot.



Regardless, I think that it's quite clear that we're not going 
to convince KingJoffrey of anything, and it's unlikely that 
he's going to convince us - though honestly, with that 
username, I have to wonder if he's complaining about this issue 
to just screw around with us for fun. But even if he's 
completely serious, I think that it's clear that at best we're 
going to agree to disagree.


- Jonathan M Davis


I prefer to think of it as a discussion. Even though I'm right ;-)

But in any case, i feel I've presented some worthwhile arguements.

The only arguments I've got so far from the other point of view, 
is that's how D does it. If you don't like it, go wrute a DIP.

Re: LDC 1.10.0 beta

[Joakim via Digitalmars-d-announce]

On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote:

On 2018-05-13 20:12, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce the first beta 
for LDC 1.10. The highlights of this version in a nutshell:


* Based on D 2.080.0.
* Supports DragonFly BSD.
* Some fixes, most notably wrt. exception stack traces on 
Linux.


Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.10.0-beta1


Thanks to all contributors!


Out of curiosity, how come the Objective-C integration seem to 
always lack behind when LDC merges a new DMD release with some 
new Objective-C integration? Is it less prioritized, not so 
much knowledge in this area, something else?


In addition to what David said, the plan is to have longer beta 
periods for ldc from here on out, which is why this ldc beta was 
released so soon after the corresponding dmd release, two weeks, 
a new record. You're free to test it out and submit issues or 
pulls before the final ldc release, as I do for Android.

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 04:22:30 UTC, Mike Parker wrote:

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:



- Object independence
- Do not violate encapsulation
- Respect the interface


This is what I don't get from your position. What is 
encapsulation? Here's what Wikipedia says [1]:


"Encapsulation is used to hide the values or state of a 
structured data object inside a class, preventing unauthorized 
parties' direct access to them. Publicly accessible methods are 
generally provided in the class (so-called getters and setters) 
to access the values, and other client classes call these 
methods to retrieve and modify the values within the object."


This has been my understanding of encapsulation since I first 
learned of it years ago. How is this broken in D? Only if you 
insist on viewing it in a strictly theoretical sense. As a 
matter of practical reality, it is not broken.


If you have access to the internals of the class, you also have 
access to the rest of the module. No client of the class 
outside of the module has any access to the implementation. I 
showed you an example earlier of how silly it would be to force 
the rest of the module to use some sort of "module private" 
interface.


The class in D *is* encapsulated. The interface *is* respected. 
I'm not sure what you mean by object independence.



[1] 
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)


Yes, it's a vague word which can be interpreted different ways.

I primarily mean the more abstract notion of 'boundaries' and 
'interfaces'.


The concept is well presented in this keynote at ACCU 2018:

https://www.youtube.com/watch?v=IP5akjPwqEA

E.g. passing from one room to another, via a door. The door 
presents the boundary, and the interface through which you access 
each room. You cannot go star trek style (yet) and just beam from 
one room to the other.


'Beam me up scotty' is just for the movies (as far as I know ;-)

Also, if there is no boundary between the orange room and the 
blue room, how would I get from the orange room to the blue room 
- or vica versa?


The only reality our brains can perceive, is the reality made of 
from boundaries and interfaces. We cannot hold all of reality in 
our head. We have to break things down into little self-contained 
chunks, and then understand how the chunks connect together.


It becomes particularly important when trying to understand 
complexity (of any kind).


943294432432812  // grr!

943_294_432_432_812 // nice

the underscore represent the boundary.
the information between boundaries is now encapsulated (because 
of that boundary)


Now, back to D...

in this example code below, the D module does not respect the 
boundary of the object.


That is, the module can beam into the object without going 
through the interface.


I struggle to understand why the module is allowed to do this - I 
really cannot get my head around any valid reason for it - I'm 
just getting told, 'that's how D does it' -or - 'it doesn't 
really bother us'.


If I cannot control the interface, and have that respected by the 
module, then this allows the kind of bugs that actually lead me 
to working out that private is not really private at all.


And that bug would not have happened in C++/Java/C# - or, as far 
as I know, Rust and Go. They would have all respected the 
boundary.


D has chosen to allow the module to disrespect the interface. Why?

(and don't tell me it does - cause the code below clearly 
demonstrates that it does not)


===
module test;

void foo()
{
Person p = new Person("King Joffrey");

// this completely bypasses my interface
// (i.e. the boundary that I set up between the class and the 
module)

p._name = "New King";

}

class Person
{
private string _name;

public void setName(string name)
{
this._name = name;
}

public this(string name)
{
_name = name;
}

}

Re: Sealed classes - would you want them in D?

[Jonathan M Davis via Digitalmars-d]

On Tuesday, May 15, 2018 04:22:30 Mike Parker via Digitalmars-d wrote:
> On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:
> > - Object independence
> > - Do not violate encapsulation
> > - Respect the interface
>
> This is what I don't get from your position. What is
> encapsulation? Here's what Wikipedia says [1]:
>
> "Encapsulation is used to hide the values or state of a
> structured data object inside a class, preventing unauthorized
> parties' direct access to them. Publicly accessible methods are
> generally provided in the class (so-called getters and setters)
> to access the values, and other client classes call these methods
> to retrieve and modify the values within the object."
>
> This has been my understanding of encapsulation since I first
> learned of it years ago. How is this broken in D? Only if you
> insist on viewing it in a strictly theoretical sense. As a matter
> of practical reality, it is not broken.
>
> If you have access to the internals of the class, you also have
> access to the rest of the module. No client of the class outside
> of the module has any access to the implementation. I showed you
> an example earlier of how silly it would be to force the rest of
> the module to use some sort of "module private" interface.
>
> The class in D *is* encapsulated. The interface *is* respected.
> I'm not sure what you mean by object independence.
>
>
> [1]
> https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

If you really insist on the viewpoint that class encapsulation means that
nothing outside of that class can access any of its private members, then
what D does definitely breaks encapsulation. But having friends in C++
already provides a way to break that. And having access levels like
protected and package break it. Ultimately, a good language provides ways to
encapsulate data and control access to the internals of a data type, but
there are a variety of ways that that can be achieved, and I don't think
that I've ever used a language that strictly enforces that nothing can
access the internals of a class. It's just that each language provides
different ways for stuff outside the class to access the class' internals.

D happens to have gone with a very liberal approach to encapsulation by
essentially making everything inside a module friends of each other. It
doesn't break the concept of encapsulation any more than C++'s friend or
Java's package attribute do. It's just a much more liberal default, and if
you're really insistent that nothing outside of a class has access to the
stuff inside a class, then D's choice is likely to be seem terrible. So, in
that sense, I can see where he's coming from, but ultimately, I think that
it's a very narrow viewpoint about what encapsulation means, and for most of
us, experience has shown that D's choice works extremely well in practice.

Either way, as long as you understand how D works with private, you have
basically the same level of control as what you get with C++ and friend.
It's just that if you _really_ don't want anything else to be a friend,
you're forced to stick it in another module. So, ultimately, I think that
it's mostly a theoretical debate. Pretty much the worst that happens is you
accidentally use a member variable directly instead of using a property
function to access it, and that's rarely a big deal. Often, it's even
desirable.

Regardless, I think that it's quite clear that we're not going to convince
KingJoffrey of anything, and it's unlikely that he's going to convince us -
though honestly, with that username, I have to wonder if he's complaining
about this issue to just screw around with us for fun. But even if he's
completely serious, I think that it's clear that at best we're going to
agree to disagree.

- Jonathan M Davis

Re: Sealed classes - would you want them in D?

[Mike Parker via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:



- Object independence
- Do not violate encapsulation
- Respect the interface


This is what I don't get from your position. What is 
encapsulation? Here's what Wikipedia says [1]:


"Encapsulation is used to hide the values or state of a 
structured data object inside a class, preventing unauthorized 
parties' direct access to them. Publicly accessible methods are 
generally provided in the class (so-called getters and setters) 
to access the values, and other client classes call these methods 
to retrieve and modify the values within the object."


This has been my understanding of encapsulation since I first 
learned of it years ago. How is this broken in D? Only if you 
insist on viewing it in a strictly theoretical sense. As a matter 
of practical reality, it is not broken.


If you have access to the internals of the class, you also have 
access to the rest of the module. No client of the class outside 
of the module has any access to the implementation. I showed you 
an example earlier of how silly it would be to force the rest of 
the module to use some sort of "module private" interface.


The class in D *is* encapsulated. The interface *is* respected. 
I'm not sure what you mean by object independence.



[1] 
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 03:32:22 UTC, Norm wrote:


I'm seeing the opposite, more and more large applications 
adopting Python as much as possible and replacing big chunks of 
the C++ core and leaving only those C++ chunks where 
performance is all that really matters.


Encapsulation boundaries are completely arbitrary and where D 
choses to draw the line works very well in practice.


Bye,
Norm


"Encapsulation boundaries are completely arbitrary.."

I love it.

We have so much to look forward to, as more and more languages, 
and more and more quality software projects, embrace that 1950's 
idiom.

[Issue 18847] std.allocator: Region uses .parent before it can be set

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

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|dlang-bugzilla@thecybershad
   ||ow.net

--

[Issue 18847] std.allocator: Region uses .parent before it can be set

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

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

--- Comment #1 from Vladimir Panteleev  ---
Some goes for BitmappedBlock and KKRegion.

ContiguousFreeList seems to have gotten this right (though with the end result
of having 8 constructor declarations).

--

Re: Sealed classes - would you want them in D?

[Norm via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:32:05 UTC, KingJoffrey wrote:

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a 
DIP if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?


I'm seeing the opposite, more and more large applications 
adopting Python as much as possible and replacing big chunks of 
the C++ core and leaving only those C++ chunks where performance 
is all that really matters.


Encapsulation boundaries are completely arbitrary and where D 
choses to draw the line works very well in practice.


Bye,
Norm

[Issue 18860] New: Destructors and postblit constructors do not appear in DDoc output

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

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

  Issue ID: 18860
   Summary: Destructors and postblit constructors do not appear in
DDoc output
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: ddoc
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

/ test.d /
///
struct S
{
/// Documentation here
this(this) {}

/// Documentation here
~this() {}
}
//

$ dmd -D -o- test.d

$ $BROWSER test.html

(Neither declarations appear in the HTML output.)

--

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Tuesday, 15 May 2018 at 02:00:17 UTC, 12345swordy wrote:

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a DIP 
if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.


- Object independence
- Do not violate encapsulation
- Respect the interface

All large software projects are done in (or moving toward) 
languages that respect these idioms.


Those that don't, are the ones we typically have problems with.

Isn't that evidence enough?

D modules provide uncontrolled violation of encapsulation (i.e 
can bypass the interface), and completely undermine these 
established idioms.


D modules, will let anyone (within that module) access your 
wallet and take whatever they want.


http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf




But C++/Java/C# users all expect private to mean private,


We expect that users C++/Java/C# to know that D is not 
C++/Java/C# and to read the specification.


Again write a DIP if this bothers you. You are not going to 
make any language changes by ranting about it on the forums.


yeah.. I get it.. don't discuss anything, don't explore ideas or 
why others might think differently, just go off and write a DIP. 
That's why DIP's are so often poorly written and not worth the 
time of those that have to look at them.


I think such talk is just a way to shut down the converation, to 
be honest.


Based on this discussion so far, what I've gauged, is that 
spending the effort to write a dip, would be pointless (at least 
at this stage).


If D ever takes off (and I'm not sure it will, precisely because 
of the way it disregards those idioms I mentioned), then more 
pressure will come on D to change - and perhaps then sufficient 
support for a DIP would be there. But I honestly don't see how it 
can take off, unless if first respects those idioms.

Re: Wait-free MPSC and MPMC implement in D

[David Nadlinger via Digitalmars-d]

On Wednesday, 9 May 2018 at 04:17:17 UTC, Shachar Shemesh wrote:

On 09/05/18 01:09, David Nadlinger wrote:
The algorithm isn't wait-free (haven't thought too carefully 
about this, though)


This mirrors a discussion I had with Maor (who originally wrote 
it). Let's see if I bring you around the way I was brought 
around.


Ah, and I've been taking Liran to be the originator of this fine 
piece of work up to now… ;)


At the API level, there are two areas where the algorithm 
*cannot* be wait free. If a consumer tries to consume from an 
empty queue, or a producer tries to produce to a full one.


True, but some applications might favour APIs which can provide 
these guarantees by blocking instead of aggressively 
early-returning. For example, one could use a helping scheme to 
implement a MPSC queue that doesn't starve any producers even if 
the queue is close to full, or a SPMC queue that doesn't starve 
any consumers even if the queue is close to empty.



Those two aside […] the algorithm actually is wait free.


Is it, though?

If we assume the usual definition of wait-freedom (bounded number 
of steps for each thread to make progress), then MCSPQueue.pop() 
is problematic, as any one thread could get persistently unlucky 
with the cas(). This could also be the case in the steady state 
with a non-empty queue; for example, if the producer pushes 
elements at a rate matching that at which (n - 1) of n consumer 
threads pop them.


I'd need to think more carefully about the 
non-sequentially-consistent isFull() before making any statements 
about SCMPQueue.


 — David

Re: returning and receiving multiple values from a function

[arturg via Digitalmars-d]

On Tuesday, 15 May 2018 at 01:40:50 UTC, timepp wrote:

Now C++ allow this in a very clean way:

std::tuple foo() {   return {128, true, 
1.5f}; }



auto [value1, value2, value3] = foo();



Would D plan to support that in syntax level?


it depends if some dip like 
https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md is accepted.

Re: Sealed classes - would you want them in D?

[12345swordy via Digitalmars-d]

On Tuesday, 15 May 2018 at 00:28:42 UTC, KingJoffrey wrote:

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a DIP 
if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries 
the programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.



Evidence for this claim please.



But C++/Java/C# users all expect private to mean private,


We expect that users C++/Java/C# to know that D is not 
C++/Java/C# and to read the specification.


Again write a DIP if this bothers you. You are not going to make 
any language changes by ranting about it on the forums.

returning and receiving multiple values from a function

[timepp via Digitalmars-d]

Now C++ allow this in a very clean way:

std::tuple foo() {   return {128, true, 
1.5f}; }



auto [value1, value2, value3] = foo();



Would D plan to support that in syntax level?

[Issue 18821] DMD segfault 2.080

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

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

--- Comment #6 from Walter Bright  ---
Thank you. I was able to reproduce the problem.

--

[Issue 18859] Silence class allocator/deallocator deprecation warning if they are marked "deprecated"

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

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

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

   What|Removed |Added

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

--

[Issue 18859] Silence class allocator/deallocator deprecation warning if they are marked "deprecated"

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

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

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

https://github.com/dlang/dmd/commit/b6f92b288a005c5334793b318c1bf2ab70152ed4
Fix Issue 18859 - Silence class allocator/deallocator deprecation warning if
they are marked "deprecated"

--

Re: Sealed classes - would you want them in D?

[KingJoffrey via Digitalmars-d]

On Monday, 14 May 2018 at 19:40:18 UTC, 12345swordy wrote:


A slippery slope fallacy isn't helping your case. Write a DIP 
if it bothers you so much, as it changes the languages 
fundamentally.



Alexander


If 'getting a module to respect the enscapsulation boundaries the 
programmer puts in place would change the language so 
'fundamentally', then the language 'already' presents big 
problems for large complex application development.


Little old me ranting about it in some DIP isn't going to do much.

D is great for small, quick stuff though - I'll give it that. I 
enjoy using D for small stuff.


But C++/Java/C# users all expect private to mean private, as it 
should, and will, like me, get a nasty shock when they come over 
to D, and discover it my mistake, as I did.


It was only through debugging my code, did I realise I had 
disprespected the boundaries I set up, because the module let me 
do it, and the compiler thought that's what I must have wanted. I 
simply could not have made that mistake in any of the other 
langauges I use.


Clearly others take a different perspective on this issue, that's 
fine, I just don't get the case they're trying to make. It hasn't 
made any sense to me thus far.


Removing respect for encapsulation boundaries, in order to 
avoiding the need for using C++ like 'friend', sounds a bit dodgy 
to me. No matter how much I think about it, I'd rather have those 
boundaries and be forced to use friends.

[Issue 18859] Silence class allocator/deallocator deprecation warning if they are marked "deprecated"

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

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Vladimir Panteleev  ---
https://github.com/dlang/dmd/pull/8247

--

Re: The #dbugfix Campaign Round 1 Report

[Mike Parker via Digitalmars-d-announce]

On Monday, 14 May 2018 at 17:22:11 UTC, 12345swordy wrote:



Be sure to post it in r/programming


This sort of community-centric post doesn't belong there. We have 
to be careful not to reinforce the perception that we're spamming 
the sub.

Re: Sealed classes - would you want them in D?

[Walter Bright via Digitalmars-d]

On 5/14/2018 1:32 AM, Piotr Mitana wrote:

OK, Walter, point for you for this :)


Welcs!

Re: `free` for struct with C bindings.

[Ali Çehreli via Digitalmars-d-learn]

On 05/14/2018 03:03 PM, Jonathan wrote:

Do I need to call the `free` function with my D code because I need to 
free memory that was allocated in C code?


Yes, you have to free the memory with C's free():

void main() {
import core.stdc.stdlib;
auto p = malloc(42);
free(p);
}

Ali

Re: `free` for struct with C bindings.

[ag0aep6g via Digitalmars-d-learn]

On 05/15/2018 12:03 AM, Jonathan wrote:

```
xcb_generic_event_t*    event;
event = xcb_wait_for_event (connection);
free (event);
```

The problem is the `free` function.  It is not provided by the library 
but is part of the C standard library (in stdlib.h).


D has the C functions in core.stdc. So:

import core.stdc.stdlib: free;

[...]
I tried using the 
`core.memory.GC.free` function from the D standard library and it 
compiled and ran but that does not necessarily mean there are not memory 
leaks (it also ran with the line entirely removed).


core.memory.GC.free is a different function. It works on GC-managed 
pointers. Don't call it on pointers that come from C libraries.

[Issue 18859] New: Silence class allocator/deallocator deprecation warning if they are marked "deprecated"

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

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

  Issue ID: 18859
   Summary: Silence class allocator/deallocator deprecation
warning if they are marked "deprecated"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

To facilitate transition from class allocators/deallocators, it would be nice
if it was possible to mark them as deprecated, which would move the deprecation
warning from the declaration to any code that uses them. This would be similar
to how deprecated unittests allow silently testing deprecated symbols.

Example:

// test.d /
class C
{
new(size_t sz) { return null; }
}

void fun()
{
new C;
}
///

Currently, this warns on line 3.

/// test.d ///
class C
{
deprecated new(size_t sz) { return null; }
}

void fun()
{
new C;
}
//

This warns both on line 3 and line 8 (usage).
It would be better to just have a warning at line 8.

--

`free` for struct with C bindings.

[Jonathan via Digitalmars-d-learn]

I am using a C bindings library 
(https://code.dlang.org/packages/xcb-d).


I am following through a tutorial that was written for the C 
library directly and just making the minor changes to make it 
work with D.


I ran into a problem. The library ends up giving me a struct 
pointer.


```
xcb_generic_event_t*event;
event = xcb_wait_for_event (connection);
free (event);
```

The problem is the `free` function.  It is not provided by the 
library but is part of the C standard library (in stdlib.h).


Do I need to call this function with my D code?  I tried using 
the `core.memory.GC.free` function from the D standard library 
and it compiled and ran but that does not necessarily mean there 
are not memory leaks (it also ran with the line entirely removed).


Do I need to call the `free` function with my D code because I 
need to free memory that was allocated in C code?

[Issue 18858] switch 'skips declaration' test only checks last declaration

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

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

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

--

[Issue 18821] DMD segfault 2.080

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

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

ag0aep6g  changed:

   What|Removed |Added

   Keywords||ice

--

[Issue 18821] DMD segfault 2.080

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

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

ag0aep6g  changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #5 from ag0aep6g  ---
Reduced further:


align(1) struct epoll_event
{
void* ptr;
}
template isAllZeroBits(epoll_event value) {}
alias isInitAllZeroBits = isAllZeroBits!(epoll_event.init);


--

DCD 0.9.7 is available

[Baz@dlang-community via Digitalmars-d-announce]

See [1]. with mostly (since v0.9.4) two possible `RangeError` 
fixed, completion on the `IfCondition` variables [2] (which was 
surprisingly not at all implemented), and freeze fixed on the 
windows version (32 bit OMF), which forced to build with an older 
DMD version.


All binaries are available directly in the release.

---
[1] https://github.com/dlang-community/DCD/releases/tag/v0.9.7
[2] https://dlang.org/spec/statement.html#IfCondition

[Issue 18858] New: switch 'skips declaration' test only checks last declaration

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

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

  Issue ID: 18858
   Summary: switch 'skips declaration' test only checks last
declaration
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

Consider:

  int test(int n)
  {
final switch(n)
{
enum e = 6;
int z = 5; // Error: switch skips declaration of variable test.z

case 1:
int y = 2;
return y;
}
  }

Good. Now reverse the enum e and int z statements, and no error will be
generated.

--

Re: Sealed classes - would you want them in D?

[12345swordy via Digitalmars-d]

On Monday, 14 May 2018 at 07:44:00 UTC, KingJoffrey wrote:

D may as well just get rid of that encapsulation concept too, 
since the class interface is pretty much moot in D modules.


Maybe.. we should even, just completely get rid of functions 
and classes - as well as all that other stupid so-called 
'structured programming' crap, which just restricts us, and 
revert to 'real' programming - using just line numbers and goto 
statements. Then, finally, we programmers can do whatever we 
want again.


Local reasoning...it's so old-school.


A slippery slope fallacy isn't helping your case. Write a DIP if 
it bothers you so much, as it changes the languages fundamentally.



Alexander

[Issue 18606] [REG2.072] "cannot append type const(T) to type T[]" in .dup

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

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

--- Comment #2 from Vladimir Panteleev  ---
The commits are big too, but if it helped, I can bisect it down to the commit.

--

[Issue 18712] [Reg 2.072] bogus "switch skips declaration" error with case in mixin

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

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #4 from Walter Bright  ---
Here's what's happening. After a case/default statement, the parser makes the
code between one case/default and the next into a scope. So it looks like:

int test(int n)
{
switch(n)
{
mixin("case 0:");
int x = 1;
return x;
case 1:
{
int y = 2;
return y;
}
default:
{
return -1;
}
}
}

and, of course, now the error message makes sense. `x` is visible to the
following two scopes, whether or not the error message is generated. Any time
the case/default is not directly in the switch body (not nested via { } or a
mixin) the implicit { } scope is not generated. Oops.

Try putting { } in various combinations, and you'll see how it all comes
unglued.

I can't think of any solution that 1) works in all cases and 2) doesn't break a
lot of existing code. So we're just stuck with it. Fortunately, there is a
workaround. Recode the switch like this:

int test(int n)
{
switch(n)
{
mixin("case 0:");
{
int x = 1;
return x;
}
case 1:
int y = 2;
return y;
default:
return -1;
}
}

I'm going to close this as WONTFIX. If anyone has a brainwave on how to make it
work in all cases without breaking code, reopen with proof.

Note that the fundamental problem is a combination of:

1. allowing case/default statements to appear inside nested scopes

2. implicit generation of scopes between case/default pairs

--

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Jonathan M Davis via Digitalmars-d]

On Monday, May 14, 2018 18:29:33 David Nadlinger via Digitalmars-d wrote:
> On Monday, 14 May 2018 at 11:53:44 UTC, Nick Treleaven wrote:
> > On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote:
> >> Yeah. It's been discussed that it should be illegal to declare
> >> a struct or class member named init, but that change has yet
> >> to happen.
> >>
> >> https://issues.dlang.org/show_bug.cgi?id=7066
> >
> > Walter and Timon have considered redefinition potentially
> > useful. A compromise would be to require `init` and `stringof`
> > to be `static`. That would probably prevent the accidental
> > conflicts that arise with `init`.
>
> Well, Walter mentioned that "so far [no use cases] have
> materialized" in 2012, and I don't think that has changed since.
>
> @disabling .init might be an exception – although one that flirts
> with grey areas in the language definition –, but that could
> still be supported while providing useful diagnostics for other
> uses.

Well, @disable this(); specifically doesn't disable init (just default
initialization) specifically because so much depends on init existing (and
the fact that you can disable default initialization is already problematic
enough as it is). So, I'd be _very_ leery of adding a way to fully disable
init. However, even if we did want to do that, that doesn't preclude making
it illegal to define init to be something else.

- Jonathan M Davis

Re: LDC 1.10.0 beta

[David Nadlinger via Digitalmars-d-announce]

On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote:
Out of curiosity, how come the Objective-C integration seem to 
always lack behind when LDC merges a new DMD release with some 
new Objective-C integration? Is it less prioritized, not so 
much knowledge in this area, something else?


Basically all of the latter – many of us LDC devs are not really 
interested in the Objective-C integration for our own/company 
use, and kinke (who has been doing virtually all of the frontend 
merging work lately) IIRC doesn't have access to an OS X box. Not 
breaking existing features without direct access to a target is 
one thing, but implementing new features off the CI only is 
another.


Help would be very welcome, though.

 — David

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[David Nadlinger via Digitalmars-d]

On Monday, 14 May 2018 at 11:53:44 UTC, Nick Treleaven wrote:

On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote:
Yeah. It's been discussed that it should be illegal to declare 
a struct or class member named init, but that change has yet 
to happen.


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


Walter and Timon have considered redefinition potentially 
useful. A compromise would be to require `init` and `stringof` 
to be `static`. That would probably prevent the accidental 
conflicts that arise with `init`.


Well, Walter mentioned that "so far [no use cases] have 
materialized" in 2012, and I don't think that has changed since.


@disabling .init might be an exception – although one that flirts 
with grey areas in the language definition –, but that could 
still be supported while providing useful diagnostics for other 
uses.


 — David

Re: Dependency injection pattern

[Ali Çehreli via Digitalmars-d-learn]

On 05/13/2018 12:42 AM, Suliman wrote:
Could anybody give small example of Dependency injection pattern? I 
googled about it, but found only C# examples and I am not quite sure how 
to use them.


Also I would like get some explanation/comments for code.


The name and the unnecessary confusion in its documentation are 
unfortunate. And if you read the Wikipedia article, you are confronted 
with pharses like "inversion of control", "passing of a dependency to a 
dependent object", etc. Lots of correct but confusing stuff...  The 
following article starts with that unfortunate confusion:



https://www.reddit.com/r/programming/comments/8cwa4o/dependency_injection_is_a_25dollar_term_for_a/

I think this part from the Wikipedia topic is what it actually is: "The 
client should accept values passed in from outside". And this is how I 
would describe it: Provide some part of an object's behavior from the 
outside, for example during its construction. (Kevlin Henney was 
popularizing the same idea as "parameterize from above.")


The following struct does not use dependency injection because it is 
printing the value in a hardcoded way:


struct S {
int i;

void foo() {
import std.stdio;
writeln("value: ", i);// Hardcoded behavior
}
}

void main() {
auto s = S();
s.foo();
}

The following struct uses dependency injection because it takes a 
printer object in its constructor and uses that object to print the value:


interface Writer {
void write(int i);
}

class XmlWriter : Writer {
void write(int i) {
import std.stdio;
writefln("%s", i);
}
}

struct S {
int i;
Writer writer;

@disable this();

this(Writer writer) {
this.writer = writer;
}

void foo() {
writer.write(i);// Uses the dependency
}
}

void main() {
auto s = S(new XmlWriter());
s.foo();
}

Ali

Re: The #dbugfix Campaign Round 1 Report

[rikki cattermole via Digitalmars-d-announce]

On 15/05/2018 5:22 AM, 12345swordy wrote:

On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote:
I planned an extended vacation with my wife around DConf this year 
and, despite my intentions before we left, fell quite far behind on my 
D duties. I'm in the process of getting caught up with everything, and 
that includes publishing the results of the first round of the 
#dbugfix campaign.


[...]


Be sure to post it in r/programming


Please don't.

There is no source code in said page and the rules of the subreddit make 
it pretty clear.

Re: The #dbugfix Campaign Round 1 Report

[12345swordy via Digitalmars-d-announce]

On Monday, 14 May 2018 at 15:23:41 UTC, Mike Parker wrote:
I planned an extended vacation with my wife around DConf this 
year and, despite my intentions before we left, fell quite far 
behind on my D duties. I'm in the process of getting caught up 
with everything, and that includes publishing the results of 
the first round of the #dbugfix campaign.


[...]


Be sure to post it in r/programming

[Issue 18821] DMD segfault 2.080

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

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

--- Comment #4 from Mr. Smith  ---
Reduced to this:

```
module test18821;

import std.experimental.allocator : makeArray;
import core.sys.linux.epoll;

class MmapPool
{
static MmapPool instance()
{
return null;
}
}

void test()
{
epoll_event[] events = MmapPool.instance.makeArray!epoll_event(0);
}
```

--

[Issue 18850] Template overload incorrectly results in recursive expansion error

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

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

Jonathan Marler  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Marler  ---
Yes I made a mistake here.  Had a temporary brain lapse.  I mean to define Foo
as a template, not a templated struct.

--

Re: Sealed classes - would you want them in D?

[Dukc via Digitalmars-d]

On Monday, 14 May 2018 at 07:59:06 UTC, Jonathan M Davis wrote:

On Monday, May 14, 2018 07:03:35 Dukc via Digitalmars-d wrote:

On Monday, 14 May 2018 at 07:02:37 UTC, Dukc wrote:

module test;
void main() { foo.i = 2; }
void foo() { static int i = 1; }



If that's what you want, just make it a module-level variable.


Well, personally I don't care much because using static mutables 
sucks anyway, and there is rarely a reason to make static 
immutables just for one function. Enums are for that.


Just pointed out that it would be consistent with how classes 
encapsulate stuff. And the same point goes for eponymous 
templates, of course.

The #dbugfix Campaign Round 1 Report

[Mike Parker via Digitalmars-d-announce]

I planned an extended vacation with my wife around DConf this 
year and, despite my intentions before we left, fell quite far 
behind on my D duties. I'm in the process of getting caught up 
with everything, and that includes publishing the results of the 
first round of the #dbugfix campaign.


As far as I'm concerned, it was a successful run. Now, I'm eager 
to improve upon it. Send some more #dbugfix nominations out into 
the ether and, while you're at it, volunteer to review some PRs. 
The issue queue isn't going to shrink all that much until the PR 
queue gets smaller.


Thanks to everyone who nominated an issue or voiced support for a 
nomination in Round 1, and thanks in advance to those who will in 
the future!


The blog:
https://dlang.org/blog/2018/05/14/the-dbugfix-campaign-round-1-report/

reddit:
https://www.reddit.com/r/d_language/comments/8jcz5n/the_dbugfix_campaign_round_1_report/

[Issue 6579] Calling static method should *require* using type and not instance, unless specified by author

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

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

Mike Franklin  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12228

--

[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes

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

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

Mike Franklin  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=6579

--

[Issue 6579] Calling static method should *require* using type and not instance, unless specified by author

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

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

Mike Franklin  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14170

--

[Issue 14170] `this` compiles in a static context

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

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

Mike Franklin  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=6579

--

[Issue 18821] DMD segfault 2.080

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

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

--- Comment #3 from Mr. Smith  ---
Created attachment 1694
  --> https://issues.dlang.org/attachment.cgi?id=1694=edit
Stack trace

--

[Issue 18821] DMD segfault 2.080

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

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

--- Comment #2 from Mr. Smith  ---
Looks like the issue was with dlib library
Uploaded stacktrace as attachment
Will try reducing code.

--

Re: iopipe v0.0.4 - RingBuffers!

[Claude via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer 
wrote:
However, I am struggling to find a use case for this that 
showcases why you would want to use it. While it does work, and 
works beautifully, it doesn't show any measurable difference 
vs. the array allocated buffer that copies data when it needs 
to extend.


I can think of a good use-case:
- Audio streaming (on embedded environment)!

If you have something like a bluetooth audio source, and alsa or 
any audio hardware API as an audio sink to speakers, you can use 
the ring-buffer as a fifo between the two.


The bluetooth source has its own pace (and you cannot control it) 
and has a variable bit-rate, whereas the sink has a constant 
bit-rate, so you have to have a buffer between them. And you want 
to reduce the CPU cost has much as possible due to embedded 
system constraints (or even real-time constraint, especially for 
audio).

[Issue 18600] Regex performance enhancement for repeated matchFirst calls

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

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

--- Comment #2 from Jon Degenhardt  ---
Phobos PR 6268 was included in LDC 1.10.0-beta1. For this release the standard
benchmark I used for the TSV Utilities improved as follows:

LDC 1.7.0 (before regression): 8.37 seconds
LDC 1.8.0 (after regression): 10.01 seconds
LDC 1.9.0 (first fixes):   9.44 seconds
LDC 1.10.0-beta1 (Phobos PR 6268):  5.85 seconds

First fixes: Phobos PR 5981, DMD PR 7599

The benchmark test used reads a TSV file line-by-line and checks individual
fields for regex matches. A significant amount of processing time is IO, so the
percentage gain on the regex portion is higher than the overall gain. The
overall gain from LDC 1.7.0 is 30%.

Test was run on MacOS, MacMini with 16GB RAM, SSD drives. The file used was
2.7GB, 14 million lines. Test info can be found here:
https://github.com/eBay/tsv-utils-dlang/blob/master/docs/ComparativeBenchmarks2018.md

Great result!

--

[Issue 18833] [REG 2.073] DMD in some cases forgets to generate wrapping TypeInfo for modifiers on classes

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

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

--- Comment #2 from Steven Schveighoffer  ---
I assumed since I reduced this from issue 17968 that it has the same regression
point (i.e. 2.073 is when it regressed). I just now tested locally and indeed,
2.073.0 shows the failure, while 2.072.2 does not.

--

[Issue 18114] [Reg 2.078] regex performance regression

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

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

--- Comment #9 from Jon Degenhardt  ---
The final performance fix was included in LDC 1.10.0-beta1. For this release
the standard benchmark I used for the TSV Utilities improved as follows:

LDC 1.7.0 (before regression):  8.37 seconds
LDC 1.8.0 (after regression):  10.01 seconds
LDC 1.9.0 (first fixes):9.44 seconds
LDC 1.10.0-beta1 (second fix):  5.85 seconds

First fixes: Phobos PR 5981, DMD PR 7599
Second fix: Phobos PR 6268

The benchmark test used reads a TSV file line-by-line and checks individual
fields for regex matches. A significant amount of processing time is IO, so the
percentage gain on the regex portion is higher than the overall gain. The
overall gain from LDC 1.7.0 is 30%.

Test was run on MacOS, MacMini with 16GB RAM, SSD drives. The file used was
2.7GB, 14 million lines. Test info can be found here:
https://github.com/eBay/tsv-utils-dlang/blob/master/docs/ComparativeBenchmarks2018.md

Great result!

--

Re: iopipe v0.0.4 - RingBuffers!

[Steven Schveighoffer via Digitalmars-d-announce]

On 5/14/18 6:02 AM, bioinfornatics wrote:

On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer wrote:
OK, so at dconf I spoke with a few very smart guys about how I can use 
mmap to make a zero-copy buffer. And I implemented this on the plane 
ride home.


However, I am struggling to find a use case for this that showcases 
why you would want to use it. While it does work, and works 
beautifully, it doesn't show any measurable difference vs. the array 
allocated buffer that copies data when it needs to extend.


If anyone has any good use cases for it, I'm open to suggestions. 
Something that is going to potentially increase performance is an 
application that needs to keep the buffer mostly full when extending 
(i.e. something like 75% full or more).


The buffer is selected by using `rbufd` instead of just `bufd`. 
Everything should be a drop-in replacement except for that.


Note: I have ONLY tested on Macos, so if you find bugs in other OSes 
let me know. This is still a Posix-only library for now, but more on 
that later...


As a test for Ring buffers, I implemented a simple "grep-like" search 
program that doesn't use regex, but phobos' canFind to look for lines 
that match. It also prints some lines of context, configurable on the 
command line. The lines of context I thought would show better 
performance with the RingBuffer than the standard buffer since it has 
to keep a bunch of lines in the buffer. But alas, it's roughly the 
same, even with large number of lines for context (like 200).


However, this example *does* show the power of iopipe -- it handles 
all flavors of unicode with one template function, is quite 
straightforward (though I want to abstract the line tracking code, 
that stuff is really tricky to get right). Oh, and it's roughly 10x 
faster than grep, and a bunch faster than fgrep, at least on my 
machine ;) I'm tempted to add regex processing to see if it still 
beats grep.


Next up (when my bug fix for dmd is merged, see 
https://issues.dlang.org/show_bug.cgi?id=17968) I will be migrating 
iopipe to depend on https://github.com/MartinNowak/io, which should 
unlock Windows support (and I will add RingBuffer Windows support at 
that point).


Enjoy!

https://github.com/schveiguy/iopipe
https://code.dlang.org/packages/iopipe
http://schveiguy.github.io/iopipe/



Hi Steve,

It is an exciting works, that could help in bioinformatics area.
Indeed in bioinformatics we are I/O bounding and we process lot of big 
files the amount of data can be in gigabytes, terabytes and even some 
times in petabytes.


So processing efficiently these amount of data is critic. Some years ago 
I got a request 'How to parse fastq file format in D?' and monarch_dodra 
wrote a really fast parser (code: http://dpaste.dzfl.pl/37b893ed )


It could be interesting to show how iopipe is fast.


Yeah, I have been working on and off with Vang Le (biocyberman) on using 
iopipe to parse such formats. He gave a good presentation at dconf this 
year on using D in bioinformatics, and I think it is a great fit for D!


At dconf, I threw together a crude fasta parser (with the intention of 
having it be the base for parsing fastq as well) to demonstrate how 
iopipe can perform while parsing such things. I have no idea how fast or 
slow it is, as I just barely got it to work (pass unit tests I made up 
based on wikipedia entry for fasta), but IMO, the direct buffer access 
makes fast parsing much more pleasant than having to deal with your own 
buffering (using phobos makes parsing a bit difficult, however, I still 
see a need for some parsing tools for iopipe).


You can find that library here: https://github.com/schveiguy/fastaq

Not being in the field of bioinformatics, I can't really say that I am 
likely to continue development of it, but I'm certainly willing to help 
with iopipe for anyone who wants to use it in this field.


-Steve

[Issue 18712] [Reg 2.072] bogus "switch skips declaration" error with case in mixin

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #3 from Walter Bright  ---
If

mixin("case 0:");

is replaced with:

{ case 0: }

it also fails in the same way.

--

[Issue 16527] extern( C++ ) Win64 build - return struct by value is broken

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

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

Ethan Watson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Ethan Watson  ---
Looks like this issue was fixed somewhere along the line. Example code works
just fine on run.dlang.org, and the interop code I was working on for C# that
was returning structs was also working just fine on DMD 2.078. No idea when
exactly this would have been fixed, but it certainly Works For Me! now.

--

Re: Is D releasing too often?

[bachmeier via Digitalmars-d]

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:

I thought I'd open it up to the community: now that you've 
experienced this faster pace, as a user of the D compilers, how 
do you like it? Would you prefer a slower release schedule, say 
3-4 major releases a year?


I would prefer to have an LTS release at most twice a year.

The first reason is that we get bugs like the installer not 
working properly. I reported this bug

https://issues.dlang.org/show_bug.cgi?id=18808
This is the sort of bug that enters when you release too 
frequently, and it's the sort of bug that causes potential users 
to give up and conclude the project has a quality problem.


The second reason is that the maintainers of libraries have to 
keep up with every release.


Reporting bugs is less likely if you need to install the latest 
release to confirm that it's still a bug. It's hard to keep up 
with language changes if you're a more casual D user like me.


Having LTS releases and making it easy for those wanting the 
latest and greatest to build the development versions would be my 
preference.

[Issue 18606] [REG2.072] "cannot append type const(T) to type T[]" in .dup

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

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

--- Comment #1 from Walter Bright  ---
(In reply to Vladimir Panteleev from comment #0)
> Introduced in https://github.com/dlang/dmd/pull/5500

This is why I don't like 700 line PRs spread across 18 files :-(

--

[Issue 1412] stringof shouldn't be shadowed by member func

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

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||n...@geany.org
 Resolution|--- |DUPLICATE

--- Comment #6 from Nick Treleaven  ---


*** This issue has been marked as a duplicate of issue 7066 ***

--

[Issue 7066] You can redefine .init and .stringof without error

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||dav...@126.com

--- Comment #12 from Nick Treleaven  ---
*** Issue 1412 has been marked as a duplicate of this issue. ***

--

Identifier from string - Re: static foreach considered

[Nick Treleaven via Digitalmars-d]

On Monday, 8 June 2015 at 21:32:52 UTC, Timon Gehr wrote:

On 06/08/2015 10:16 PM, Idan Arye wrote:

It would be nice together with this feature to be able to mixin
identifiers:

 static foreach (ident; ["foo", "bar"])
 {
 auto mixin(ident)()
 {
 // code for foo/bar
 }
 }

+1. Other use cases:

auto mixin(ident) = x;

identifier.list.mixin(ident).foo();

import std.mixin(ident);


Browsing bugzilla, I've discovered Idan's feature was actually 
proposed in 2009, but with different syntax:


int __ident(name)() {...}

This seems better syntax, see:
https://issues.dlang.org/show_bug.cgi?id=2698#c3

[Issue 18473] [Reg 2.078.1] std.math.approxEqual no longer accepts nested ranges

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

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |FIXED

--- Comment #1 from Walter Bright  ---
Fixed by https://github.com/dlang/phobos/pull/6213

--

[Issue 18833] [REG 2.073] DMD in some cases forgets to generate wrapping TypeInfo for modifiers on classes

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Since this is marked as a regression, when did it work?

--

[Issue 14170] `this` compiles in a static context

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simen.kja...@gmail.com

--- Comment #1 from Simen Kjaeraas  ---
(1) is a case of DMD ignoring a redundant keyword - 'static' has no effect
there, so it's just ignored. It's been mentioned that this is due to static
blocks in aggregates, but I'm unsure of the exact details:

struct S {
static { // or just static:
// lots of declarations
alias value this;
}
}


(3) is explicitly mentioned in https://dlang.org/spec/declaration.html#typeof:

Special cases:

typeof(this) will generate the type of what this would be in a non-static
member function, even if not in a member function.


(2) and (4) are bug 6579. Possibly a bit more than that, since they don't have
an actual instance to work with, but that's the root.

--

[Issue 18821] DMD segfault 2.080

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
Can you produce a smaller test case? Or run it under the debugger to find out
where in DMD it is faulting?

--

[Issue 2698] Syntax to parse an identifier from a string, instead of mixin()

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

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

Nick Treleaven  changed:

   What|Removed |Added

Summary|Parameterised identifier|Syntax to parse an
   ||identifier from a string,
   ||instead of mixin()

--

[Issue 2698] Parameterised identifier

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #3 from Nick Treleaven  ---
(In reply to Daniel Keep from comment #0)
>   int __ident(name)() { return __ident("_"~name~"storage"); }
Wow, this was an insightful idea from 2009! It has recently been re-discovered
in 2015:

https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1010.md#mixin-identifiers

I prefer the __identifier(ident) syntax than mixin(ident), it's less noisy as:

1. it doesn't get highlighted as a keyword.
2. it's clearer what kind of token is being introduced.
3. it doesn't refine the idea of mixin to more than just expressions/statements
(i.e. code, not an identifier).

--

[Issue 14064] Error message about @ attributes incomplete.

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

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||trivial
 CC||n...@geany.org

--

[Issue 15501] Missing parens for template argument in error message: Error: no property 'nsecs' for type 'MonoTimeImpl!cast(ClockType)0'

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

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||trivial
 CC||n...@geany.org

--

[Issue 14854] @disable this inconsistent between structs and classes

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

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

Nick Treleaven  changed:

   What|Removed |Added

   Keywords||trivial
 CC||n...@geany.org

--

[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes

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

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

Nick Treleaven  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14170

--

[Issue 14170] `this` compiles in a static context

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12228

--

[Issue 8162] [TDPL] -property fails to give an error when a property function is called with parens

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

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

--- Comment #7 from Nick Treleaven  ---
*** Issue 7307 has been marked as a duplicate of this issue. ***

--

[Issue 7307] Not fully enforced properties syntax

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

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Nick Treleaven  ---


*** This issue has been marked as a duplicate of issue 8162 ***

--

[Issue 18857] New: [std.experimental.logger] use NullLogger as the default

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

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

  Issue ID: 18857
   Summary: [std.experimental.logger] use NullLogger as the
default
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: singingb...@hotmail.com

use NullLogger as the default instead of outputting to stderr

--

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Nick Treleaven via Digitalmars-d]

On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote:
Yeah. It's been discussed that it should be illegal to declare 
a struct or class member named init, but that change has yet to 
happen.


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


Walter and Timon have considered redefinition potentially useful. 
A compromise would be to require `init` and `stringof` to be 
`static`. That would probably prevent the accidental conflicts 
that arise with `init`.

[Issue 8161] -property should give an error for invalid property functions

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #5 from Nick Treleaven  ---
> s.prop = AliasSeq!(1, 2);
> I agree that it should be disallowed
Yes, because otherwise the restriction to a maximum of 2 arguments doesn't make
sense.

--

[Issue 7066] You can redefine .init and .stringof without error

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #11 from Nick Treleaven  ---
struct S {
string stringof;
}

// Issue 14237
class MyClass
{
void init() {};
}

`init` and `stringof` should be required to be `static`, as they are expected
to work without an instance. They should probably not be allowed to be `void`
functions either.

--

[Issue 14237] Compiler should reject attempts to (re)define .init

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

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Nick Treleaven  ---


*** This issue has been marked as a duplicate of issue 7066 ***

--

[Issue 13943] Grammar does not list 'super' and 'this' as types

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

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull
 CC||slavo5...@yahoo.com

--- Comment #2 from Mike Franklin  ---
PR: https://github.com/dlang/dmd/pull/8242

--

[Issue 7066] You can redefine .init and .stringof without error

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||heartcollector...@gmail.com

--- Comment #10 from Nick Treleaven  ---
*** Issue 14237 has been marked as a duplicate of this issue. ***

--

[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes

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

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

Nick Treleaven  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13943

--

[Issue 13943] Grammar does not list 'super' and 'this' as types

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=12228

--- Comment #1 from Nick Treleaven  ---
As Issue 9597 has been fixed, it looks like these keywords will no longer be
accepted as types - see the recent pull for Issue 12228.

--

Re: serialport v1.0.0

[Russel Winder via Digitalmars-d-announce]

On Sun, 2018-05-13 at 12:05 -0600, Jonathan M Davis via Digitalmars-d-announce 
wrote:
[…]
> 
> Really? If the consensus is that it should go in, then okay, but I don't
> think that I've ever seen a standard library with anything like
> functionality for talking to serial ports. And what would having it be in
> Phobos buy you over just grabbing it from code.dlang.org?

Python is a batteries included distribution.

PySerial and PySerial-AsyncIO  are packages in PyPI, not in the distibution,
and sometime packaged in OS package repositories..

-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #10 from Nick Treleaven  ---
It's great that `this` doesn't work as a type in a parameter list now Issue
18228 is fixed, but `super` should probably be disallowed too:

class A
{
void foo(super i) {}
}

--

[Issue 6454] @property doesn't need return type

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

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

Nick Treleaven  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||n...@geany.org
 Resolution|--- |INVALID

--- Comment #4 from Nick Treleaven  ---
The spec has been updated to list `Property` under `StorageClass`:

https://dlang.org/spec/declaration.html#StorageClass

--

[Issue 18853] std.allocator: AllocatorList fails to allocate after a deallocation

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

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

alex.jercai...@gmail.com changed:

   What|Removed |Added

 CC||alex.jercai...@gmail.com
   Assignee|edi33...@gmail.com  |alex.jercai...@gmail.com

--

Re: D GPU execution module: A survey of requirements.

[bioinfornatics via Digitalmars-d]

On Thursday, 10 May 2018 at 07:25:32 UTC, Nicholas Wilson wrote:

On Thursday, 10 May 2018 at 00:10:07 UTC, H Paterson wrote:

On Wednesday, 9 May 2018 at 23:37:14 UTC, Henry Gouk wrote:

On Wednesday, 9 May 2018 at 23:26:19 UTC, H Paterson wrote:

Hello,

I'm interested in writing a module for executing D code on 
GPUs. I'd like to bounce some ideas off D community members 
to see what this module needs do.


[...]


Check out https://github.com/libmir/dcompute


Welp... It's not quite what I would have envisioned, but seems 
to fill the role.


Thanks for pointing Dcompute out to me - I only found it 
mentioned in a dead link on the D wiki.


Time to find a new project...


It's not dead, it's just pining for the fjords^H^H^H^H  
hibernating waiting for me to finish undergrad (~7 weeks). You 
are more than welcome to join the development.


Nic


Dcompute seems really promising, unfortunately I have not yet 
successfully build the ldc compiler using a LLVM fork with SPIRV 
enabled: https://github.com/libmir/dcompute/issues/46


Maybe you should try with a ldc 1.7 or less (I tried 1.8 and 1.9 )

Good luck

Re: iopipe v0.0.4 - RingBuffers!

[bioinfornatics via Digitalmars-d-announce]

On Thursday, 10 May 2018 at 23:22:02 UTC, Steven Schveighoffer 
wrote:
OK, so at dconf I spoke with a few very smart guys about how I 
can use mmap to make a zero-copy buffer. And I implemented this 
on the plane ride home.


However, I am struggling to find a use case for this that 
showcases why you would want to use it. While it does work, and 
works beautifully, it doesn't show any measurable difference 
vs. the array allocated buffer that copies data when it needs 
to extend.


If anyone has any good use cases for it, I'm open to 
suggestions. Something that is going to potentially increase 
performance is an application that needs to keep the buffer 
mostly full when extending (i.e. something like 75% full or 
more).


The buffer is selected by using `rbufd` instead of just `bufd`. 
Everything should be a drop-in replacement except for that.


Note: I have ONLY tested on Macos, so if you find bugs in other 
OSes let me know. This is still a Posix-only library for now, 
but more on that later...


As a test for Ring buffers, I implemented a simple "grep-like" 
search program that doesn't use regex, but phobos' canFind to 
look for lines that match. It also prints some lines of 
context, configurable on the command line. The lines of context 
I thought would show better performance with the RingBuffer 
than the standard buffer since it has to keep a bunch of lines 
in the buffer. But alas, it's roughly the same, even with large 
number of lines for context (like 200).


However, this example *does* show the power of iopipe -- it 
handles all flavors of unicode with one template function, is 
quite straightforward (though I want to abstract the line 
tracking code, that stuff is really tricky to get right). Oh, 
and it's roughly 10x faster than grep, and a bunch faster than 
fgrep, at least on my machine ;) I'm tempted to add regex 
processing to see if it still beats grep.


Next up (when my bug fix for dmd is merged, see 
https://issues.dlang.org/show_bug.cgi?id=17968) I will be 
migrating iopipe to depend on 
https://github.com/MartinNowak/io, which should unlock Windows 
support (and I will add RingBuffer Windows support at that 
point).


Enjoy!

https://github.com/schveiguy/iopipe
https://code.dlang.org/packages/iopipe
http://schveiguy.github.io/iopipe/

-Steve


Hi Steve,

It is an exciting works, that could help in bioinformatics area.
Indeed in bioinformatics we are I/O bounding and we process lot 
of big files the amount of data can be in gigabytes, terabytes 
and even some times in petabytes.


So processing efficiently these amount of data is critic. Some 
years ago I got a request 'How to parse fastq file format in D?' 
and monarch_dodra wrote a really fast parser (code: 
http://dpaste.dzfl.pl/37b893ed )


It could be interesting to show how iopipe is fast.

You can grab a fastq file from 
ftp://ftp.1000genomes.ebi.ac.uk/vol1/ftp/phase3/data/HG00096/sequence_read/ and take a look at iopipe perf .


fastq file is plain test format and it is usually a repetition of 
four lines:

1/ title and description
this line starts with @
2/ sequence line
this line contains ususally DNA letters (ACGT)
3/ comment line
this line starts with +
4/ quality of amino acids
this line has the same length as the sequence line (n°2)

Rarely, the comment section is over multiple lines.
Warning the @ and + characters can be found inside the quality 
line, thus I search a pattern of two characters '\n@' and '\n+'. 
I never split file by line as it is a waste of time instead I 
read the content as a stream.


I hope this show case help you

Good luck :-)

Re: Is D releasing too often?

[Dejan Lekic via Digitalmars-d]

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:
There have been 6 major releases of dmd over the last year, 
with ldc trying to keep pace, currently only one release 
behind. This is a big jump up from the previous release 
schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 
2016.


There are obviously pros and cons to each pace, and this has 
been debated internally before, with one of the ldc devs again 
posting to the Internals mailing list today questioning the 
current speed.


I thought I'd open it up to the community: now that you've 
experienced this faster pace, as a user of the D compilers, how 
do you like it? Would you prefer a slower release schedule, say 
3-4 major releases a year?


I thought 6/year was an ambitious schedule when announced and I 
wonder if it isn't putting too much strain on our few release 
maintainers, maybe 3-4 releases/year would be a more gradual 
bump up.


I have nothing against releasing that often as long as there is a 
LTS version, and that is where the problem lies - we do not have 
it. So what I do is simply base my production code on particular 
release, and every few months allocate few days job to try to 
bring the code up-to-date with latest DMD.

[Issue 15869] RVO can overwrite argument

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

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

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

https://github.com/dlang/dmd/commit/0ba1f25c99bfd6e02b64b3b283540ed74e97fca5
fix Issue 15869 - RVO can overwrite argument

https://github.com/dlang/dmd/commit/68eb9d341ccd0b7872ce719df07da268398dc3aa
Merge pull request #8200 from WalterBright/fix15869

fix Issue 15869 - RVO can overwrite argument
merged-on-behalf-of: Razvan Nitu 

--

[Issue 15869] RVO can overwrite argument

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

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

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

   What|Removed |Added

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

--

Re: Is D releasing too often?

[bauss via Digitalmars-d]

On Monday, 14 May 2018 at 07:53:40 UTC, Jonathan M Davis wrote:

On Monday, May 14, 2018 07:20:48 Joakim via Digitalmars-d wrote:
There have been 6 major releases of dmd over the last year, 
with ldc trying to keep pace, currently only one release 
behind. This is a big jump up from the previous release 
schedule, I see 2 major releases in 2014, 3 in 2015, and 3 in 
2016.


There are obviously pros and cons to each pace, and this has 
been debated internally before, with one of the ldc devs again 
posting to the Internals mailing list today questioning the 
current speed.


I thought I'd open it up to the community: now that you've 
experienced this faster pace, as a user of the D compilers, 
how do you like it? Would you prefer a slower release 
schedule, say 3-4 major releases a year?


I thought 6/year was an ambitious schedule when announced and 
I wonder if it isn't putting too much strain on our few 
release maintainers, maybe 3-4 releases/year would be a more 
gradual bump up.


I think that most of us are fine with how it's been going, but 
a large percentage of the work for putting out each release 
goes to Martin, and he's been talking about reducing the pace 
to something more like one major release every 6 months, which 
I think would be too slow. I don't want to have to wait that 
long for improvements to Phobos to become available. Quarterly 
would be okay, I guess, but it's always frustrating when an 
improvement makes it into Phobos but you can't use it for 
months, because you have to wait for it to be released - and 
it's even worse when you want to then be able to build your 
code with ldc, since they're always behind.


- Jonathan M Davis


Honestly Phobos should be released independently from DMD (But 
should still be shipped with it of course.)


Library implementations shouldn't wait for the compiler to be 
available.


That's just my opinion though

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/14/2018 04:35 AM, Uknown wrote:


Agree, but I think LTS releases are worth considering. A yearly release 
that gets only bug fixes would be useful for stability.


A fair point. I have no disagreement with something like that.

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

Ie, as long as there's no regression problems: If the rate of releases 
makes us feel like we have an embarrassment of riches, it doesn't mean 
that we *NEED* fewer releases. It means we need to be more appreciative 
that there's all those enhancements we don't have to wait for.

Re: Is D releasing too often?

[Uknown via Digitalmars-d]

On Monday, 14 May 2018 at 08:29:30 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 05/14/2018 03:20 AM, Joakim wrote:

[..]
Summary (That's "TL:DR" in hipster parlance): **Available** 
updates are always a good thing, as long as they're checked for 
regressions. Any issues keeping up with updates only indicate 
we have a *good* problem: That the ecosystem has room for 
"process" improvements and isn't currently being constrained by 
lack of progress in dependencies.


Agree, but I think LTS releases are worth considering. A yearly 
release that gets only bug fixes would be useful for stability.

Re: Sealed classes - would you want them in D?

[Piotr Mitana via Digitalmars-d]

On Saturday, 12 May 2018 at 15:36:56 UTC, Walter Bright wrote:

On 5/12/2018 8:18 AM, Piotr Mitana wrote:

What I am trying to do is:



== a.d 

class P
{
private this();
}

final class C1 : P { }
final class C2 : P { }

 test.d 

import a;

void foo()
{
P[] twoPs = [ new C1(), new C2() ]; // works
}

class C3 : P   // fails
{
}



dmd test a
Error: constructor a.P.this is not accessible from module test


OK, Walter, point for you for this :)

I still think that this is a kind of a hack (if I need to create 
an instance of P directly, I need a factory method - it's also 
not that clean and obvious), but in fact it effectively seems to 
do what I want to achieve.


Although I consider sealed as a nice addition still to make 
things nice and clean, I understand that it may be not enough 
justified to add a new keyword to the language. Thank you for all 
the opinions on that. :)

Re: Is D releasing too often?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 05/14/2018 03:20 AM, Joakim wrote:
There have been 6 major releases of dmd over the last year, with ldc 
trying to keep pace, currently only one release behind. This is a big 
jump up from the previous release schedule, I see 2 major releases in 
2014, 3 in 2015, and 3 in 2016.




This is just a return to the old original pace. It used to be about this 
often, but improved focus on avoiding regressions and packaging mistakes 
had a side effect of delaying releases down to as low as 2/year. But the 
improved "checks and balances and procedures" have finally become 
streamlined enough that the delays have been overcome and we're back to 
where we already were.


Personally, I like it. Keep in mind, availability of an update does not 
mandate immediate upgrading. It's just means its *available*. In an 
ideal world, improvements should be available immediately. In the real 
world, we have need to allow for both automated and manual checks for 
regressions. Therefore, the only things that should delay deployment of 
a project's new releases are:


A. Automated regression tests (and fixing found regressions).
B. A formal "beta" cycle (and fixing found regressions).
C. The existence of improvements (without improvements, what's the point 
of a new release?).


If dependent projects/libs have trouble keeping up with an increased 
rate of releases, that only means that we need better tools for 
automating the tasks involved in supporting newer releases.


If there's motivation to delay releases, that's a clear indication that 
dependent projects are in simply need of better automation/processes/etc.


Summary (That's "TL:DR" in hipster parlance): **Available** updates are 
always a good thing, as long as they're checked for regressions. Any 
issues keeping up with updates only indicate we have a *good* problem: 
That the ecosystem has room for "process" improvements and isn't 
currently being constrained by lack of progress in dependencies.