Re: newCTFE Status March 2018

[Meta via Digitalmars-d]

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

Hello Guys,

I took a few days off over easter and I have very good news for 
you.
The following code will now compile and execute correctly using 
newCTFE.


---
class C
{
  int i() {return 1;}
}

class D : C
{
  override int i() {return 2;}
  float f() { return 1.0f; }
}

class E : D
{
  override int i() {return 3;}
  override float f() { return 2.0f; }
}


int testClassStuff ()
{
  C c1, c2, c3;
  D c4;
  c1 = new C();
  c2 = new D();
  c3 = new E();

  D e = new E();
  assert(cast(int)e.f() == 2);

  return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
---

In short this means that classes and virtual function calls 
work now.
albeit currently only if you don't define your own constructor, 
which would currently get treated as normal function and 
therefore not set the vtbl pointer correctly.


I'd also like to note that the vtbl handling is backend 
independent which means that you code your own backend for 
newCTFE without having to deal with the fact that vtbl and 
constructor stuff is going on.

To you It's just load store and call. :)

Have a nice easter.

Stefan


newCTFE is looking very cool. Glad to see you're still working at 
it.

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 30 March 2018 at 18:52, Walter Bright via Digitalmars-d
 wrote:
> On 3/30/2018 6:03 PM, Manu wrote:
>>
>> Sadly, I don't think I'll be able to make it to DConf this year...
>
>
> :-(
>
>> which is probably a reason for rejoice of literally everybody
>> attending! :P
>
>
> You'll be missed.

Thank your stars... I wouldn't be able to resist heckling everyone on
this the whole time! :P

[Issue 18223] std.experimental.allocator uninitializedFillDefault could use memset

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

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

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

   What|Removed |Added

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

--

[Issue 18223] std.experimental.allocator uninitializedFillDefault could use memset

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

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

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

https://github.com/dlang/phobos/commit/8777cbf35505704bc2908baa4ae04d988f339bf8
Fix Issue 18223: use memset in uninitializedFillDefault(T[])

When we can statically determine that the representation of T.init
consists of nothing but zeroes or nothing but ones we use memset.
(The second case occurs for char and wchar.)

https://github.com/dlang/phobos/commit/6797b52c0d99980b645bcbaf75c8bd6acf0b9613
Merge pull request #6024 from n8sh/uninitializedFillDefault-memset

Fix Issue 18223: use memset in uninitializedFillDefault(T[])
merged-on-behalf-of: unknown

--

Re: Beta 2.079.0

[meppl via Digitalmars-d-announce]

On Saturday, 31 March 2018 at 00:25:47 UTC, Seb wrote:
On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak 
wrote:

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:

[...]


No need to use it if you don't like it. It's particularly 
useful for small examples, localized imports and hacking.
It's mainly a generalisation of the existing possibility to 
mix module imports and one selective import at the end.
If you prefer java-like 50 lines import manifests, then by all 
means keep using those.

How would that feature cause bugs though?


AFAICT Rust now has introduced the exactly same feature. It's 
quite interesting to see that there was no outcry by the 
community and it was universally liked:


https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
https://github.com/rust-lang/rust/issues/44494


the curly brackets make the rust implementation more readable. 
The dmd implementation didn't use brackets. I believe that's a 
main reason for the resistance from the people

Re: How would you create this construct?

[Chris Katko via Digitalmars-d-learn]

On Friday, 30 March 2018 at 03:14:42 UTC, Mike Parker wrote:

On Friday, 30 March 2018 at 02:30:01 UTC, Chris Katko wrote:

[...]


Something like this?

=
import std.stdio;

[...]


This is beautiful. I mean, the struct stuff looks 
complicated/non-intuitive at first, but it's all boilerplate.

[Issue 18595] std.random: add unpredictableSeedOf!UIntType for non-uint unpredictableSeed

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

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

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

--

Re: rvalues -> ref (yup... again!)

[Jonathan M Davis via Digitalmars-d]

On Friday, March 30, 2018 18:52:38 Walter Bright via Digitalmars-d wrote:
> On 3/30/2018 6:03 PM, Manu wrote:
> > Sadly, I don't think I'll be able to make it to DConf this year...
> :
> :-(
> :
> > which is probably a reason for rejoice of literally everybody
> > attending! :P
>
> You'll be missed.

My usual response to that is that it's better to be missed than to be hit.
;)

But yes, it will be a shame if it's unable to come.

- Jonathan M Davis

Re: rvalues -> ref (yup... again!)

[Jonathan M Davis via Digitalmars-d]

On Friday, March 30, 2018 18:03:49 Manu via Digitalmars-d wrote:
> On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d
> > And honestly, I don't really want to encourage the use of const. It's
> > fine if folks use it where it really works, and it's potentially even
> > quite valuable there, but it seems like too often folks try to add
> > const in places where it's just going to cause problems. It's
> > particularly bad when folks try to add const to generic code - e.g. we
> > recently had to revert a commit to std.random which worked with dynamic
> > arrays but not other ranges because of const. And there have been other
> > cases where folks have wanted to try to make stuff in Phobos
> > "const-correct", which would cause problems. So, I'm not a big fan of
> > the idea of doing anything that would make folks want to use const
> > more.
>
> It's interesting... I recognise the general backlash against const. I
> personally just make myself a `struct Mutable(T) { ... }` which I use
> when I want to violate const ;)

Just don't do anything where you cast away const and then mutate. That
violates the type system and results in undefined behavior. And depending on
what the compiler chooses to do based on const, you could get some rather
subtle and nasty bugs.

> But if it turns out that const is useless, then we really need to
> reconsider the basic design of const >_<
> Like, what's the point? You're advocating active discouragement of
> const... why is there a feature which it's accepted is a loaded-gun?
> Handing it to people creates a high probability they'll shoot
> themselves in the feet.

const makes some sense when you want to write code that accepts both mutable
and immutable arguments, and there are times where it works perfectly fine
to use const. I see no problem with using const in such situations. The
problem is that there are a _lot_ cases where const simply can't be used in
D, because you need to mutate _something_ involved, even if it's not
something that's part of the "logical" state of the object - e.g. in D, you
can't put a mutex in a type and then have it protect anything in a const
member function, because locking the mutex would require mutating it, and D
provides no backdoors like C++'s mutable. What's const is actually const.

Also, const tends to interact very badly with generic code. Whatever API
you're duck typing has to include const as part of it, or you can't use
const - e.g. ranges can't be const, because they have to be mutated to be
iterated, and because the range API does not require that properties like
front or empty be const, no generic code can assume that even those work
with const (and for many ranges, they _can_'t be const - especially when one
range wraps another). In general, it can be quite difficult to even do
something like have a tail-const range over a container. Sometimes, const
can be made to work in more complex situations, but often it can't, and when
it can't, it's often a royal pain.

For non-generic code that can clearly treat an object as fully const without
needing any backdoors, const is just fine, and it may even help prevent
bugs. But for a _lot_ of code - especially idiomatic D code that does a lot
with templates and ranges - const simply doesn't work.

So, const can be used on some level, but anyone who tries to be
"const-correct" in D like many of us usually try to do in C++ is in for a
world of frustration.

If you haven't, I'd suggest that you read this article I recently wrote on
the topic:

http://jmdavisprog.com/articles/why-const-sucks.html

And here's the newsgroup thread discussing it:

https://forum.dlang.org/thread/mailman.581.1520247475.3374.digitalmars-d-annou...@puremagic.com

> > Now, if you can convince Walter and Andrei to allow const ref to accept
> > rvalues, then fine. I think that that's definitely worse than an
> > attribute specifically for that, given how limiting const is, but it
> > wouldn't screw up normal ref in the process, which is what I'm most
> > worried about here. So, I don't think that going with const would be
> > the best solution to the problem, but it's far better than making ref
> > in general accept rvalues.
>
> Useful examples using 'return ref' have been presented, which I find
> quite compelling too. That's an interesting case of non-const ref.
> Safe to say I'm not convincing anyone of anything in any way other
> than DIP form.

Yes, at this point, convincing Walter or Andrei will require writing a DIP.
A well-written proposal that clearly doesn't have the downsides that they're
so against may have a chance with them, but without something that formally
and clearly provides the arguments, I don't think that they're even going to
pay much attention at this point. The topic has been debated to death
previously, and without a DIP, it really doesn't matter what Walter and
Andrei think, since at this point, they wouldn't introduce a language change
like that without a DIP. So, they'll just do 

Re: rvalues -> ref (yup... again!)

[Walter Bright via Digitalmars-d]

On 3/30/2018 6:03 PM, Manu wrote:

Sadly, I don't think I'll be able to make it to DConf this year...


:-(


which is probably a reason for rejoice of literally everybody
attending! :P


You'll be missed.


It would be nice to workshop it in person though.

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d
 wrote:
> On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote:
>> On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d
>> > I want to be able to look at a function signature, see ref without other
>> > qualifiers, and be reasonably certain that the function is supposed to
>> > be
>> > mutating that argument, whereas if ref by itself accepted rvalues, then
>> > we lose that. If an attribute were used to make it allow rvalues, then
>> > we wouldn't.
>>
>> I don't know any reason why someone wouldn't attribute the argument
>> 'const' if it doesn't intend to write to it. Likewise 'return ref' if
>> it's going to be modified and returned.
>> I'm not sure your concern is actually a thing...?
>
> const would do it, but given how restrictive const is in D, I don't see how
> it would be very reasonable to restrict passing rvalues to const.

I'm actually coming around to the idea of not restricting it to const...
But what I'm trying to say is, the number of cases where your
principle will feel violated should be as infrequent as the cases
where const is insufficient for 'reasons' ;)
As far as I know, in usages that I've ever encountered, I can't
imagine a case where you would feel violated :)


> And honestly, I don't really want to encourage the use of const. It's fine if
> folks use it where it really works, and it's potentially even quite valuable
> there, but it seems like too often folks try to add const in places where
> it's just going to cause problems. It's particularly bad when folks try to
> add const to generic code - e.g. we recently had to revert a commit to
> std.random which worked with dynamic arrays but not other ranges because of
> const. And there have been other cases where folks have wanted to try to
> make stuff in Phobos "const-correct", which would cause problems. So, I'm
> not a big fan of the idea of doing anything that would make folks want to
> use const more.

It's interesting... I recognise the general backlash against const. I
personally just make myself a `struct Mutable(T) { ... }` which I use
when I want to violate const ;)
But if it turns out that const is useless, then we really need to
reconsider the basic design of const >_<
Like, what's the point? You're advocating active discouragement of
const... why is there a feature which it's accepted is a loaded-gun?
Handing it to people creates a high probability they'll shoot
themselves in the feet.


> Now, if you can convince Walter and Andrei to allow const ref to accept
> rvalues, then fine. I think that that's definitely worse than an attribute
> specifically for that, given how limiting const is, but it wouldn't screw up
> normal ref in the process, which is what I'm most worried about here. So, I
> don't think that going with const would be the best solution to the problem,
> but it's far better than making ref in general accept rvalues.

Useful examples using 'return ref' have been presented, which I find
quite compelling too. That's an interesting case of non-const ref.
Safe to say I'm not convincing anyone of anything in any way other
than DIP form.


But I'd like to understand your concern better. You say it's about
scanning an API and understanding some details from it based on seeing
'ref' written there... how does a function accepting an rvalue
interact with your visibility of the API?
Like, your criticism is with respect to understanding the API at a
glance... I don't understand how this proposal interferes with that in
any way?

Sadly, I don't think I'll be able to make it to DConf this year...
which is probably a reason for rejoice of literally everybody
attending! :P
It would be nice to workshop it in person though.

Re: Beta 2.079.0

[Seb via Digitalmars-d-announce]

On Tuesday, 20 February 2018 at 08:43:50 UTC, Martin Nowak wrote:

On Monday, 19 February 2018 at 15:58:57 UTC, Joakim wrote:
17. Allow multiple selective imports from different modules in 
a single import statement


I have a bad feeling that that one is going to be a source of 
a raft of bugs for years to come.


No need to use it if you don't like it. It's particularly 
useful for small examples, localized imports and hacking.
It's mainly a generalisation of the existing possibility to mix 
module imports and one selective import at the end.
If you prefer java-like 50 lines import manifests, then by all 
means keep using those.

How would that feature cause bugs though?


AFAICT Rust now has introduced the exactly same feature. It's 
quite interesting to see that there was no outcry by the 
community and it was universally liked:


https://blog.rust-lang.org/2018/03/29/Rust-1.25.html
https://github.com/rust-lang/rust/issues/44494

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

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

https://github.com/dlang/dmd/commit/978cb051c2f4b3f716a330032280aee234214db8
Fix Issue 18688 - Constructors shouldn't have implicit super call if it throws

https://github.com/dlang/dmd/commit/830f9e0ed422887193b6c7454a940c7a92b05de8
Merge pull request #8100 from RazvanN7/Issue_18688

Fix Issue 18688 - Constructors shouldn't have implicit super call if it throws
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 18688] Constructors shouldn't have implicit super call if it throws

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

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

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

   What|Removed |Added

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

--

Re: Fast GC allocation of many small objects

[Alexandru Jercaianu via Digitalmars-d-learn]

On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu 
wrote:

On Friday, 30 March 2018 at 20:46:43 UTC, Per Nordlöw wrote:
On Friday, 30 March 2018 at 20:38:35 UTC, rikki cattermole 
wrote:
Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)


https://dlang.org/phobos/std_experimental_allocator.html

is massive.

I guess I should allocate my nodes using

auto node = theAllocator.make!StrNode("alpha");

Could someone please give a working example of a GC-backed 
`theAllocator` suitable for my allocation pattern?


Hello,

You can try the following:
struct Node
{
char[64] arr;
}

 enum numNodes = 100_000_000;
 void[] buf = GCAllocator.instance.allocate(numNodes * 
Node.sizeof);

 auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);

 foreach(i; 0 .. numNodes)
 {
 Node* n = cast(Node*)(reg.allocate(Node.sizeof).ptr);
 // do stuff with the new node
 }

I benchmarked this versus
 foreach(i; 0 .. numNodes)
 {
 auto n = new Node;
 // do stuff...
 }

The first approach was about 30% faster.


Sorry, I forgot to add which imports you need:

 import std.experimental.allocator.gc_allocator;
 import std.experimental.allocator.building_blocks.region;
 import std.experimental.allocator.building_blocks.null_allocator;

Re: rvalues -> ref (yup... again!)

[Jonathan M Davis via Digitalmars-d]

On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote:
> On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d
> > I want to be able to look at a function signature, see ref without other
> > qualifiers, and be reasonably certain that the function is supposed to
> > be
> > mutating that argument, whereas if ref by itself accepted rvalues, then
> > we lose that. If an attribute were used to make it allow rvalues, then
> > we wouldn't.
>
> I don't know any reason why someone wouldn't attribute the argument
> 'const' if it doesn't intend to write to it. Likewise 'return ref' if
> it's going to be modified and returned.
> I'm not sure your concern is actually a thing...?

const would do it, but given how restrictive const is in D, I don't see how
it would be very reasonable to restrict passing rvalues to const. And
honestly, I don't really want to encourage the use of const. It's fine if
folks use it where it really works, and it's potentially even quite valuable
there, but it seems like too often folks try to add const in places where
it's just going to cause problems. It's particularly bad when folks try to
add const to generic code - e.g. we recently had to revert a commit to
std.random which worked with dynamic arrays but not other ranges because of
const. And there have been other cases where folks have wanted to try to
make stuff in Phobos "const-correct", which would cause problems. So, I'm
not a big fan of the idea of doing anything that would make folks want to
use const more.

Now, if you can convince Walter and Andrei to allow const ref to accept
rvalues, then fine. I think that that's definitely worse than an attribute
specifically for that, given how limiting const is, but it wouldn't screw up
normal ref in the process, which is what I'm most worried about here. So, I
don't think that going with const would be the best solution to the problem,
but it's far better than making ref in general accept rvalues.

- Jonathan M Davis

Re: Fast GC allocation of many small objects

[Alexandru Jercaianu via Digitalmars-d-learn]

On Friday, 30 March 2018 at 20:46:43 UTC, Per Nordlöw wrote:
On Friday, 30 March 2018 at 20:38:35 UTC, rikki cattermole 
wrote:
Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)


https://dlang.org/phobos/std_experimental_allocator.html

is massive.

I guess I should allocate my nodes using

auto node = theAllocator.make!StrNode("alpha");

Could someone please give a working example of a GC-backed 
`theAllocator` suitable for my allocation pattern?


Hello,

You can try the following:
struct Node
{
char[64] arr;
}

 enum numNodes = 100_000_000;
 void[] buf = GCAllocator.instance.allocate(numNodes * 
Node.sizeof);

 auto reg = Region!(NullAllocator, 16)(cast(ubyte[])buf);

 foreach(i; 0 .. numNodes)
 {
 Node* n = cast(Node*)(reg.allocate(Node.sizeof).ptr);
 // do stuff with the new node
 }

I benchmarked this versus
 foreach(i; 0 .. numNodes)
 {
 auto n = new Node;
 // do stuff...
 }

The first approach was about 30% faster.

[Issue 18698] static foreach + __traits(allMembers, moduleName)

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

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

--- Comment #1 from Manu  ---
I try this:

  module test;
  alias Members = __traits(allMembers, test);

> Error: basic type expected, not `__traits`

We *really* need to fix that one...

So:

  module test;
  import std.meta;
  alias Members = AliasSeq!(__traits(allMembers, test));
  pragma(msg, Members);

> tuple("object", "std", "arr", "t", "Members")

Okay, that's good.

  static foreach(m; Members)
  {
pragma(msg, m);
  }

Error: template instance AliasSeq!(__traits(allMembers, test)) recursive
template expansion


Oh dear...

--

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d
 wrote:
> On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote:
>> On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d
>>
>>  wrote:
>> > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky  via Digitalmars-d
>> >
>> > wrote:
>> >> On 03/23/2018 09:06 PM, Jonathan M Davis wrote:
>> >> > My biggest concern in all of this is that I don't want to see ref
>> >> > start
>> >> > accepting rvalues as has been occasionally discussed. It needs to be
>> >> > clear when a function is accept an argument by ref because it's going
>> >> > to mutate the object and when it's accepting by ref because it wants
>> >> > to
>> >> > avoid a copy.
>> >>
>> >> That ship sailed ages ago: It's already unclear. If we want to fix
>> >> that,
>> >> we can fix it, but blocking rvalue ref does nothing for that cause.
>> >
>> > Really? And how often does ref get used just to avoid copying? You can
>> > almost always look at a function, see that it accepts ref, and know that
>> > it's supposed to mutate the argument. Functions that want to avoid
>> > copying lvalues usually use auto ref, not ref, whereas if ref accepted
>> > rvalues, a number of folks would start using it all over the place to
>> > avoid copying. Right now, folks rarely use ref that way, because it
>> > becomes too annoying to call the function with an rvalue. So, while it
>> > might not be the case 100% of the time right now that ref is used with
>> > the purpose of mutating the argument, it almost always is. As such, you
>> > can pretty reliably look at a function signature and expect that if one
>> > of its parameters is ref, it's going to be mutating that argument. The
>> > function that accepts an argument by ref with no intention of mutating
>> > it is very much the exception, and I really don't want to see that
>> > change.
>>
>> Interesting. Just understand that you're trading that feeling for a
>> suite of edge cases though. Accepting asymmetric calling rules is a
>> pretty big cost to pay for that 'nice thought'.
>> That idea also dismisses the existence of the set of cases where ref
>> is genuinely useful/correct. Your sentiment effectively puts those use
>> cases into the position of 2nd-class citizens.
>> I understand your sentiment, but I think the cost is not balanced, or
>> even particularly fair with respect to users in those niche groups :/
>
> I'm not arguing against having a way to indicate that a parameter accepts
> both rvalues and lvalues and that the rvalues get copied to an invisible
> variable so that they can be passed as an lvalue. I'm arguing against simply
> making ref have that behavior. Assuming that the details of how that worked
> internally didn't involve problematic stuff like the rvalue reference stuff
> that Andrei and Walter are so against, having an attribute such as @rvalue
> to attach to a ref parameter to allow it to accept rvalues would be fine
> with me. I just don't want ref by itself to lose its current semantics,
> because that would dilute its meaning and increase its amiguity.

https://imgflip.com/i/27gjv9


> I want to be able to look at a function signature, see ref without other
> qualifiers, and be reasonably certain that the function is supposed to be
> mutating that argument, whereas if ref by itself accepted rvalues, then we
> lose that. If an attribute were used to make it allow rvalues, then we
> wouldn't.

I don't know any reason why someone wouldn't attribute the argument
'const' if it doesn't intend to write to it. Likewise 'return ref' if
it's going to be modified and returned.
I'm not sure your concern is actually a thing...?

[Issue 18698] New: static foreach + __traits(allMembers, moduleName)

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

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

  Issue ID: 18698
   Summary: static foreach + __traits(allMembers, moduleName)
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

I just tried to write some code that I've been using for 10 years... but it's
not working today.

This works:
  module test;
  pragma(msg, __traits(allMembers, test));

Prints: tuple("object", "std", "numberOf", "arr", "t")


This should work, but doesn't:
  module test;
  static foreach(m; __traits(allMembers, test))
  {
pragma(msg, m);
  }

Prints: Compiling C:\Code\blah.d failed!

Nice informative error ;)


I've been scanning the module for things since I started using D, but today, it
doesn't seem to work...

This is actually really serious. A huge amount of my compile-time machinery is
broken now! I can't serialise, or do any of my DLL machinery, dynamic language
bindings... :/

--

Re: D compiles fast, right? Right??

[Seb via Digitalmars-d]

On Friday, 30 March 2018 at 20:40:16 UTC, Stefan Koch wrote:
On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu 
wrote:

On 3/30/18 12:12 PM, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a 
D file:


     import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

     /tmp % time dmd -c  foo.d
     dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


Could be faster.


That... doesn't seem too fast to me. But wait, there's more:

     /tmp % time dmd -c -unittest foo.d
     dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
0.525 total


Not fast. We need to make -unittest only affect the built 
module. Even though it breaks certain uses of 
__traits(getUnittests). No two ways about it. Who can work on 
that?


Andrei


unittests by nature usually have a short list of dependencies 
and therefore their compilation can be parallelized.
There are many performance leaks we can fix, before we need to 
think about breaking useful features!


No one wants to run the std.regex's testsuite when they pass 
-unittest or instantiate and run all tests for all Tuple 
combinations present.
If you can make dmd so fast that this happens unnoticed, that 
would be amazing, otherwise I suggest we don't run Phobos's 
templated unittests in user-code.

Re: Fast GC allocation of many small objects

[rikki cattermole via Digitalmars-d-learn]

On 31/03/2018 9:46 AM, Per Nordlöw wrote:

On Friday, 30 March 2018 at 20:38:35 UTC, rikki cattermole wrote:
Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)


https://dlang.org/phobos/std_experimental_allocator.html

is massive.

I guess I should allocate my nodes using

     auto node = theAllocator.make!StrNode("alpha");

Could someone please give a working example of a GC-backed 
`theAllocator` suitable for my allocation pattern?


The default theAllocator is the GC :)

Also see[0] and "Sample Assembly"[1] which will really interest you I think.

[0] https://dlang.org/phobos/std_experimental_allocator_gc_allocator.html
[1] https://dlang.org/phobos/std_experimental_allocator_building_blocks.html

Re: newCTFE Status March 2018

[Stefan Koch via Digitalmars-d]

On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

[...]


How close are you to finish this?


85 to 90% maybe.

I expect that there will many bugs which were hidden by newCTFE 
not supporting classes, which will now be out in the open and 
have to be dealt with.
Also the code is in need of cleanup before I would release it for 
upstream-inclusion.

Re: Fix transposed ranges

[Cym13 via Digitalmars-d-learn]

On Friday, 30 March 2018 at 20:43:09 UTC, Cym13 wrote:
Hi, I've got the following code that takes a list of files as 
argument and xor them together (demo example sufficient for 
that discussion).


[...]


Forgot to mention but I'm also quite annoyed at the need for that 
".array" because "transposed" requires the RoR to be assignable. 
That kills the laziness. I'm very much open to suggestions 
regarding that point.

Re: Fast GC allocation of many small objects

[Per Nordlöw via Digitalmars-d-learn]

On Friday, 30 March 2018 at 20:38:35 UTC, rikki cattermole wrote:
Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)


https://dlang.org/phobos/std_experimental_allocator.html

is massive.

I guess I should allocate my nodes using

auto node = theAllocator.make!StrNode("alpha");

Could someone please give a working example of a GC-backed 
`theAllocator` suitable for my allocation pattern?

Fix transposed ranges

[Cym13 via Digitalmars-d-learn]

Hi, I've got the following code that takes a list of files as 
argument and xor them together (demo example sufficient for that 
discussion).


import std.stdio;
import std.array;
import std.range;
import std.algorithm;

auto rawContent(string path) {
return File(path).byChunk(16384).joiner;
}

void main(string[] args) {
args[1..$]
.map!rawContent
.array
.transposed
.map!(bytes => bytes.fold!((a, b) => a^b))
.writeln;
}

This works but compiles with deprecations:

/usr/include/dlang/dmd/std/algorithm/iteration.d(663): 
Deprecation: function `std.range.Transposed!(Result[], 
cast(TransverseOptions)0).Transposed.save` is deprecated - This 
function is incorrect and will be removed November 2018. See the 
docs for more details.
/usr/include/dlang/dmd/std/algorithm/iteration.d(663): 
Deprecation: function `std.range.Transposed!(Result[], 
cast(TransverseOptions)0).Transposed.save` is deprecated - This 
function is incorrect and will be removed November 2018. See the 
docs for more details.


What do you think the best course of action would be to make that 
code resilient to the modification of transposed? I'd very *very* 
much like to keep a straight UFCS line, there's really nothing 
complicated enough with this operation to warrant writting 
boilerplate, yet the straightforward solution isn't 
future-proof...


Any idea?

Re: D compiles fast, right? Right??

[Stefan Koch via Digitalmars-d]

On Friday, 30 March 2018 at 20:17:39 UTC, Andrei Alexandrescu 
wrote:

On 3/30/18 12:12 PM, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a D 
file:


     import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

     /tmp % time dmd -c  foo.d
     dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


Could be faster.


That... doesn't seem too fast to me. But wait, there's more:

     /tmp % time dmd -c -unittest foo.d
     dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
0.525 total


Not fast. We need to make -unittest only affect the built 
module. Even though it breaks certain uses of 
__traits(getUnittests). No two ways about it. Who can work on 
that?


Andrei


unittests by nature usually have a short list of dependencies and 
therefore their compilation can be parallelized.
There are many performance leaks we can fix, before we need to 
think about breaking useful features!

Re: Fast GC allocation of many small objects

[rikki cattermole via Digitalmars-d-learn]

On 31/03/2018 9:31 AM, Per Nordlöw wrote:
I'm working on a graph database with tens of millions of small nodes 
containing typically around 8-64 bytes of member data. Is there a faster 
way of allocating many small class objects such as


class Node
{
     // abstract members
}

class StrNode : Node
{
     string value;
}

// more Node-types...

other than

const nodeCount = 10_000_000;
foreach (0 .. n)
{
     auto node = new Node(someData);
     // connect node...
}


Use a custom allocator (that could be backed by the GC) using 
std.experimental.allocators :)

Re: __has_side_effects

[Stefan Koch via Digitalmars-d]

On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that 
(I assume) yields true if the given expression has no side 
effects.


In D the primitive would be called e.g. __has_side_effects to 
avoid confusion with the "const" qualifier.


I wonder how difficult it would be to define __has_side_effects 
(it would apply to an alias) and how it can be put to good use.



Andrei


It's actually quite easy.
make a function literal annotated with pure and call your 
function, if that returns the function had no side effects.
if something is constant you can determine by using at in ctfe 
context, if that function call does not compile then it is not a 
constant.

Fast GC allocation of many small objects

[Per Nordlöw via Digitalmars-d-learn]

I'm working on a graph database with tens of millions of small 
nodes containing typically around 8-64 bytes of member data. Is 
there a faster way of allocating many small class objects such as


class Node
{
// abstract members
}

class StrNode : Node
{
string value;
}

// more Node-types...

other than

const nodeCount = 10_000_000;
foreach (0 .. n)
{
auto node = new Node(someData);
// connect node...
}

__has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that (I 
assume) yields true if the given expression has no side effects.


In D the primitive would be called e.g. __has_side_effects to avoid 
confusion with the "const" qualifier.


I wonder how difficult it would be to define __has_side_effects (it 
would apply to an alias) and how it can be put to good use.



Andrei

Re: D compiles fast, right? Right??

[Seb via Digitalmars-d]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a D 
file:


import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

/tmp % time dmd -c  foo.d
dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


We had a recent discussion about this:

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

tl;dr:
- e.g. all unicode tables are probably imported and CTFE-ed 
(that's a huge chunk)
- Vladimir has written an excellent tool (-> 
https://github.com/CyberShadow/DBuildStat)

Re: newCTFE Status March 2018

[Per Nordlöw via Digitalmars-d]

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

Have a nice easter.

Stefan


Great, then there's hope.

Re: D compiles fast, right? Right??

[Andrei Alexandrescu via Digitalmars-d]

On 3/30/18 12:12 PM, Atila Neves wrote:

Fast code fast, they said. It'll be fun, they said. Here's a D file:

     import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

     /tmp % time dmd -c  foo.d
     dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


Could be faster.


That... doesn't seem too fast to me. But wait, there's more:

     /tmp % time dmd -c -unittest foo.d
     dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 0.525 total


Not fast. We need to make -unittest only affect the built module. Even 
though it breaks certain uses of __traits(getUnittests). No two ways 
about it. Who can work on that?


Andrei

Re: newCTFE Status March 2018

[12345swordy via Digitalmars-d]

On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

Hello Guys,

I took a few days off over easter and I have very good news for 
you.
The following code will now compile and execute correctly using 
newCTFE.


---
class C
{
  int i() {return 1;}
}

class D : C
{
  override int i() {return 2;}
  float f() { return 1.0f; }
}

class E : D
{
  override int i() {return 3;}
  override float f() { return 2.0f; }
}


int testClassStuff ()
{
  C c1, c2, c3;
  D c4;
  c1 = new C();
  c2 = new D();
  c3 = new E();

  D e = new E();
  assert(cast(int)e.f() == 2);

  return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
---

In short this means that classes and virtual function calls 
work now.
albeit currently only if you don't define your own constructor, 
which would currently get treated as normal function and 
therefore not set the vtbl pointer correctly.


I'd also like to note that the vtbl handling is backend 
independent which means that you code your own backend for 
newCTFE without having to deal with the fact that vtbl and 
constructor stuff is going on.

To you It's just load store and call. :)

Have a nice easter.

Stefan


How close are you to finish this?

[Issue 18649] curl on Ubuntu 18.04 depends on libcurl4, .deb installer depends on libcurl3

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

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

--- Comment #6 from Seb  ---
An attempt at fixing it by simply making libcurl optional (it's only needed for
std.net.curl) https://github.com/dlang/installer/pull/314

--

Re: D compiles fast, right? Right??

[bachmeier via Digitalmars-d]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:


/tmp % time dmd -c  foo.d
dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


That... doesn't seem too fast to me. But wait, there's more:

/tmp % time dmd -c -unittest foo.d
dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
0.525 total




I did the same timings on my computer, and I got 0.128s and 
0.272s. I'm on DMD 2.075.1, so something must have changed in 
std.path since then.

newCTFE Status March 2018

[Stefan Koch via Digitalmars-d]

Hello Guys,

I took a few days off over easter and I have very good news for 
you.
The following code will now compile and execute correctly using 
newCTFE.


---
class C
{
  int i() {return 1;}
}

class D : C
{
  override int i() {return 2;}
  float f() { return 1.0f; }
}

class E : D
{
  override int i() {return 3;}
  override float f() { return 2.0f; }
}


int testClassStuff ()
{
  C c1, c2, c3;
  D c4;
  c1 = new C();
  c2 = new D();
  c3 = new E();

  D e = new E();
  assert(cast(int)e.f() == 2);

  return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
---

In short this means that classes and virtual function calls work 
now.
albeit currently only if you don't define your own constructor, 
which would currently get treated as normal function and 
therefore not set the vtbl pointer correctly.


I'd also like to note that the vtbl handling is backend 
independent which means that you code your own backend for 
newCTFE without having to deal with the fact that vtbl and 
constructor stuff is going on.

To you It's just load store and call. :)

Have a nice easter.

Stefan

Re: How to use chromium embedded framework in dlang ?

[Jayam via Digitalmars-d]

On Friday, 30 March 2018 at 13:00:42 UTC, JN wrote:

On Thursday, 29 March 2018 at 19:09:47 UTC, Jayam wrote:
How to create desktop application using chromium embedded 
framework in dlang


Not sure how up to date is it, but you can give 
https://github.com/DerelictOrg/DerelictCEF a go.


I have tried but lot of error occurred. It would be helpful if 
any sample cod.

Re: rvalues -> ref (yup... again!)

[Jonathan M Davis via Digitalmars-d]

On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote:
> On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d
>
>  wrote:
> > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky  via Digitalmars-d
> >
> > wrote:
> >> On 03/23/2018 09:06 PM, Jonathan M Davis wrote:
> >> > My biggest concern in all of this is that I don't want to see ref
> >> > start
> >> > accepting rvalues as has been occasionally discussed. It needs to be
> >> > clear when a function is accept an argument by ref because it's going
> >> > to mutate the object and when it's accepting by ref because it wants
> >> > to
> >> > avoid a copy.
> >>
> >> That ship sailed ages ago: It's already unclear. If we want to fix
> >> that,
> >> we can fix it, but blocking rvalue ref does nothing for that cause.
> >
> > Really? And how often does ref get used just to avoid copying? You can
> > almost always look at a function, see that it accepts ref, and know that
> > it's supposed to mutate the argument. Functions that want to avoid
> > copying lvalues usually use auto ref, not ref, whereas if ref accepted
> > rvalues, a number of folks would start using it all over the place to
> > avoid copying. Right now, folks rarely use ref that way, because it
> > becomes too annoying to call the function with an rvalue. So, while it
> > might not be the case 100% of the time right now that ref is used with
> > the purpose of mutating the argument, it almost always is. As such, you
> > can pretty reliably look at a function signature and expect that if one
> > of its parameters is ref, it's going to be mutating that argument. The
> > function that accepts an argument by ref with no intention of mutating
> > it is very much the exception, and I really don't want to see that
> > change.
>
> Interesting. Just understand that you're trading that feeling for a
> suite of edge cases though. Accepting asymmetric calling rules is a
> pretty big cost to pay for that 'nice thought'.
> That idea also dismisses the existence of the set of cases where ref
> is genuinely useful/correct. Your sentiment effectively puts those use
> cases into the position of 2nd-class citizens.
> I understand your sentiment, but I think the cost is not balanced, or
> even particularly fair with respect to users in those niche groups :/

I'm not arguing against having a way to indicate that a parameter accepts
both rvalues and lvalues and that the rvalues get copied to an invisible
variable so that they can be passed as an lvalue. I'm arguing against simply
making ref have that behavior. Assuming that the details of how that worked
internally didn't involve problematic stuff like the rvalue reference stuff
that Andrei and Walter are so against, having an attribute such as @rvalue
to attach to a ref parameter to allow it to accept rvalues would be fine
with me. I just don't want ref by itself to lose its current semantics,
because that would dilute its meaning and increase its amiguity.

I want to be able to look at a function signature, see ref without other
qualifiers, and be reasonably certain that the function is supposed to be
mutating that argument, whereas if ref by itself accepted rvalues, then we
lose that. If an attribute were used to make it allow rvalues, then we
wouldn't.

- Jonathan M Davis

Re: std.variant Is Everything Cool About D

[Walter Bright via Digitalmars-d-announce]

On 3/29/2018 12:32 PM, Walter Bright wrote:

On 3/29/2018 10:30 AM, 12345swordy wrote:

There are some quite criticisms being made in the comments section.


The main criticism is a misunderstanding about std.variant's allocation 
strategy. I have been trying to correct that.


Part of the problem is the documentation for std.variant is not clear about when 
memory allocation happens. It also is not clear that "boxing" means "allocates 
space for the data on the GC heap and stores a pointer to it in the variant".

Re: How to customize vibe.data.json

[kerdemdemir via Digitalmars-d-learn]

On Friday, 30 March 2018 at 17:58:23 UTC, Seb wrote:

On Friday, 30 March 2018 at 16:47:52 UTC, kerdemdemir wrote:

Hi,

In vibe's web 
page(http://vibed.org/api/vibe.data.json/serializeToJson) it 
is told that I should implement


[...]


I think you are looking for this - 
https://github.com/vibe-d/vibe.d/pull/2088


Feel free to ping the people there ;-)


struct RESTTime {
SysTime time;
alias time this;
static RESTTime fromString(string v) { return
RESTTime(SysTime.fromSimpleString(v)); }
string toString() const { return time.toSimpleString(); }
}

struct TradeData
{
UUID   sellOrderID;
UUID   buyOrderID;  

SysTime buyOrderTime;
SysTime sellOrderTime;  
}

void main() {

TradeData t;
Json jsonResult = t.serializeToJson();
writeln(jsonResult.toString());

}

Unfortunately what is shown in the forum is not working with 
SysTime.
My program is being terminated in 
std.datetime.SysTime.toISOExtString() function by code -11.


I hope it does not sound like spoon feeding but do you know any 
solution for SysTime. I am working on it in parallel.


Erdem

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 30 March 2018 at 02:47, Kagamin via Digitalmars-d
 wrote:
>
> The only criticism against rvalue references I saw was when the
> reference outlives the temporary.

That's the only *technical* criticism I've ever heard too.
Fortunately, D now has mechanisms for preventing that; D's @safety
story with respect to reference lifetime seems to be solid now.
'return ref', and enforcing ref pointers don't escape the callee
cleared to the road to allow accepting temporaries safety.

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 30 March 2018 at 02:06, Atila Neves via Digitalmars-d
 wrote:
> On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote:
>>
>> On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d
>>  wrote:
>>>
>>> On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote:


 On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d
  wrote:
>
>
> On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote:
>>
>>
>
>>> That's _if_ T is big and _if_ it even gets copied,
>>
>>
>> You've just described the exact anatomy of a ref function!
>> You wouldn't write a function to receive T by ref UNLESS T was both
>> big, and the function probably won't inline (therefore definitely
>> copy), and that condition will be triggered by any of the list of
>> reasons I've said a bunch of times (extern, dll, lib, virtual, etc).
>> People don't just love writing ref (well, some people might), but they
>> use it deliberately, typically in user-facing boundary API's for these
>> exact reasons.
>
>
> I know. I was arguing that those cases are uncommon and the API pain is
> therefore not too big of an issue. I'm pretty sure that you feel it more
> because of what you write in D.

Totally.
But I think it's uncommon at least in-part because of this
inconvenience. It's at least a little bit circular. Even you're saying
above "yeah, just do by-val, it's *probably* insignificant"... you
only say that because you've allowed this inconvenience to change your
behaviour. And I think that's to be expected.
Other reasons that it's not common:
extern(C++) is not common.
OOP (virtuals) in D are fairly uncommon. We don't OOP much in D.
Closed-source (binary lib) distribution is uncommon... possibly
unheard of? (yet!)
DLL's are still problematic onvarious fronts, and I don't think they
enjoy anywhere near as much use as they deserve.

Most of these aren't desirable... we'd like to see more commercial
(closed source?) users, DLL's should be more popular than they are...
and more extern(C++) means more people using a key development
investment in D.
So yeah, I agree it's relatively uncommon if you don't interact with
one of the niches where it tends to be common! :P


>> Right. I'm talking about deliberate use of ref... Or *existing*
>> (deliberate) use of ref, as is the case in almost all my my cases. The
>> code already exists.
>
>
> Right, and I was assuming (perhaps incorrectly) that this existing code was
> C++, hence me being on board with binding rvalues to const ref there.

Right. But I'm not a fan is just rearranging the edge cases by
limiting it to a different set of cases and not applying it generally.
This also interacts with meta constructions, and while there are ANY
cases where calling doesn't just work as usual and it needs special
case handling, meta will still need static-if's to handle those cases.
We're just changing the criteria for the 'if'.
By allowing fully symmetric function calling rules, only then does the
noisy case-handling logic disappear from meta.


>> Only if you ARE moving, and not copying. D must deep copy too if you
>> actually copy.
>> Your example assumes C++ doesn't have a move constructor. D has
>> implicit move semantics, so you can only make an equivalent comparison
>> where C++ also defines the move constructor so the move case doesn't
>> pollute the ref comparison.
>
> I wasn't assuming the lack of a move constructor. What I was saying is that
> passing by value in C++ will usually mean a copy, whereas in D it usually
> means a move.

Right. But we're not talking about move's, we're talking about
NOT-move's (ie, preventing copies by passing by ref) ;)
Despite the appearance that we might be talking about rvalues, we're
actually talking about passing lvalues by ref... that's WHY you write
a function to accept its args by ref; to prevent deep copies when
passing lvalues.
The issue is, it's super-common to call functions with rvalues, and
the edge cases created by using ref are annoying and asymmetric, hence
such functions should receive rvalues too.


 In C++'s case, it's not that references were deficient at being
 references that C++ needed rval-references, it's that references were
 deficient at being move-able.
>>>
>>> There were deficient at being moveable because temporaries can bind to
>>> const T&.
>>
>> ... what? That's just not true at all.
>> If temporaries couldn't bind to C++ ref, then you *definitely*
>> wouldn't be able to move it, because you can guarantee that someone
>> else owns the reference.
>
> Precisely. That's how D works.

Sorry, I'm lost now. I don't understand your initial point. You
created a relationship between ref's accepting rvalues, and the reason
that C++ introduced rvalue-references.
No such relationship exists... and I was trying to show that your
reasoning was inverted.


>> rvalue references were introduced in C++ to capture the calls with
>> rvalues into 

Re: How to customize vibe.data.json

[kerdemdemir via Digitalmars-d-learn]

On Friday, 30 March 2018 at 17:58:23 UTC, Seb wrote:

On Friday, 30 March 2018 at 16:47:52 UTC, kerdemdemir wrote:

Hi,

In vibe's web 
page(http://vibed.org/api/vibe.data.json/serializeToJson) it 
is told that I should implement


[...]


I think you are looking for this - 
https://github.com/vibe-d/vibe.d/pull/2088


Feel free to ping the people there ;-)


Exactly :)

Re: rvalues -> ref (yup... again!)

[Manu via Digitalmars-d]

On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d
 wrote:
> On Thursday, March 29, 2018 23:28:54 Nick Sabalausky  via Digitalmars-d
> wrote:
>> On 03/23/2018 09:06 PM, Jonathan M Davis wrote:
>> > My biggest concern in all of this is that I don't want to see ref start
>> > accepting rvalues as has been occasionally discussed. It needs to be
>> > clear when a function is accept an argument by ref because it's going
>> > to mutate the object and when it's accepting by ref because it wants to
>> > avoid a copy.
>> That ship sailed ages ago: It's already unclear. If we want to fix that,
>> we can fix it, but blocking rvalue ref does nothing for that cause.
>
> Really? And how often does ref get used just to avoid copying? You can
> almost always look at a function, see that it accepts ref, and know that
> it's supposed to mutate the argument. Functions that want to avoid copying
> lvalues usually use auto ref, not ref, whereas if ref accepted rvalues, a
> number of folks would start using it all over the place to avoid copying.
> Right now, folks rarely use ref that way, because it becomes too annoying to
> call the function with an rvalue. So, while it might not be the case 100% of
> the time right now that ref is used with the purpose of mutating the
> argument, it almost always is. As such, you can pretty reliably look at a
> function signature and expect that if one of its parameters is ref, it's
> going to be mutating that argument. The function that accepts an argument by
> ref with no intention of mutating it is very much the exception, and I
> really don't want to see that change.

Interesting. Just understand that you're trading that feeling for a
suite of edge cases though. Accepting asymmetric calling rules is a
pretty big cost to pay for that 'nice thought'.
That idea also dismisses the existence of the set of cases where ref
is genuinely useful/correct. Your sentiment effectively puts those use
cases into the position of 2nd-class citizens.
I understand your sentiment, but I think the cost is not balanced, or
even particularly fair with respect to users in those niche groups :/

Re: How to customize vibe.data.json

[Seb via Digitalmars-d-learn]

On Friday, 30 March 2018 at 16:47:52 UTC, kerdemdemir wrote:

Hi,

In vibe's web 
page(http://vibed.org/api/vibe.data.json/serializeToJson) it is 
told that I should implement


[...]


I think you are looking for this - 
https://github.com/vibe-d/vibe.d/pull/2088


Feel free to ping the people there ;-)

Re: LDC 1.8.0

[Matthias Klumpp via Digitalmars-d-announce]

On Thursday, 29 March 2018 at 08:10:11 UTC, Martin Tschierschke 
wrote:
On Saturday, 24 March 2018 at 17:33:18 UTC, Matthias Klumpp 
wrote:
On Tuesday, 13 March 2018 at 01:52:48 UTC, Matthias Klumpp 
wrote:

[...]
Aww, just a little bit too late to easily get into Ubuntu 
18.04 LTS


Well It still made it, yay! (Even without me explicitly 
requesting it)
This means Ubuntu 18.04 will be pretty up-to-date when it 
comes to D stuff, only GDC 8 won't be the default (but still 
available).
The thing that is facilitating an up-to-date D stack in Debian 
and Ubuntu is software in the archive using D. The Tilix 
terminal emulator is at the forefront there, followed by my 
appstream-generator and the Laniakea archive management suite 
and all the bits and pieces those projects depend on (like 
GtkD in Tilix' case).


This is very cool! Will DMD become part of Ubuntu, too?


No, it's too late for that and adding DMD to Debian (and thereby 
Ubuntu) would be a significant amount of work.
For compiling D code in Debian/Ubuntu, we will pretty much always 
use LDC or GDC, because we want stronger optimization and better 
architecture support, while compilation time doesn't matter at 
all.
That being said, with DMD being under a completely free license 
now, the only thing that is preventing it from being in Debian is 
lack of manpower in the D team (having it would be very useful!).
So, if anyone is interested in helping out with maintaining 
compiler packages, D libraries or tools, please join the Debian D 
team![1].
You don't have to be a Debian developer to help, but you should 
ideally be somewhat familiar with Debian's policies and 
packaging. Me or others in the D team who are Debian developers 
can review the changes and sponsor them into the Debian and 
Ubuntu archives.


Since Ubuntu 18.04 LTS releases this April, getting DMD in that 
release will be almost impossible (feature freeze is very soon), 
but we could have it in Ubuntu 18.10, if someone creates packages 
for it.


[1]: https://salsa.debian.org/d-team/ - get a guest account: 
https://signup.salsa.debian.org/

Re: #dbugfix Issue 16486 200$

[9il via Digitalmars-d]

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[1] https://issues.dlang.org/show_bug.cgi?id=16486



Solving this may be possible for special cases but in the 
general case is infeasible.


Can the case where the name of original template in scope of the 
alias template refers to an unique template template be 
implemented? It should be good enough for Mir and Phobos.


// There are unique defs for OriginalTemplate and ParamsMap
import lala : OriginalTemplate, ParamsMap;
alias AliasTemplate(SomeParams...) = 
OriginalTemplate!(ParamsMap!SomeParams);

How to customize vibe.data.json

[kerdemdemir via Digitalmars-d-learn]

Hi,

In vibe's web 
page(http://vibed.org/api/vibe.data.json/serializeToJson) it is 
told that I should implement


Json toJson() const;
static T fromJson(Json src);

string toString() const;
static T fromString(string src);

I think I should implement those as member functions(I am not 
sure).


I have a struct like:

struct TradeData
{
import std.uuid : UUID;
import std.datetime : SysTime;

UUID   sellOrderID;
UUID   buyOrderID;
SysTime buyOrderTime;
SysTime sellOrderTime;  
}

What I want is automatically json conversion of UUID and SysTime 
classes by returning UUID.toString() and SysTime.toSimpleString() 
methods when serializeToJson() is being called. Since these are 
std classes I don't know how can I manipulate them.


Can you please tell me how should I use toJson(), fromJson() 
functions for customizing user defined objects.


Erdem

Re: D compiles fast, right? Right??

[Jonathan Marler via Digitalmars-d]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a D 
file:


import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

/tmp % time dmd -c  foo.d
dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


That... doesn't seem too fast to me. But wait, there's more:

/tmp % time dmd -c -unittest foo.d
dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
0.525 total



Half. A. Second. AKA "an eternity" in dog years, err, CPU time. 
I know this has been brought up before, and recently even, but, 
just... just... sigh.


So I wondered how fast it'd be in Go, since it's got a 
reputation for speedy compilation:


package foo
import "path"
func Foo() string {
return path.Base("foo")
}

/tmp % time go tool compile foo.go
go tool compile foo.go  0.01s user 0.01s system 117% cpu 
0.012 total



See, now that's what I'd consider fast. It has actual code in 
the file because otherwise it complains the file isn't using 
the imported package, because, Go things. It compiled so fast I 
had to check I'd generated an object file, and then I learned 
you can't use objdump on Go .o files, because... more Go things 
(go tool objdump for the curious).


Ok, so how about C++, surely that will make D look good?

#include   // yes, also a one-liner

/tmp % time /usr/bin/clang++ -std=c++17 -c foo.cpp
/usr/bin/clang++ -std=c++17 -c foo.cpp  0.45s user 0.03s 
system 96% cpu 0.494 total


/tmp % time /usr/bin/g++ -std=c++17 -c foo.cpp
/usr/bin/g++ -std=c++17 -c foo.cpp  0.39s user 0.04s system 
99% cpu 0.429 total



So yeeah. If one is compiling unit tests, which I 
happen to pretty much only exclusively do, then trying to do 
anything with paths in D is


1. Comparable to C++ in build times
2. Actually _slower_ than C++ (who'd've thunk it?) *
3. Gets lapped around Captain America vs The Falcon style about 
50 times by Go.


And that's assuming there's a crazy D programmer out there 
(hint: me) that actually tries to compile minimal units at a 
time (with actual dependency tracking!) instead of the whole 
project at once, otherwise it'll take even longer. And this to 
just import `std.path`, then there's the actual work you were 
trying to get to.


Today actually made me want to write Go. I'm going to take a 
shower now.


Atila

* Building a whole project in C++ still takes a lot longer 
since D scales much better, but that's not my typical worflow, 
nor should it be anyone else's.


Seems like you're comparing apples to oranges.

Go's path.go is very small, a 215 line file:
https://github.com/golang/go/blob/master/src/path/path.go
Documentation: https://golang.org/pkg/path/


Dlang's std.path is much more comprehensive with 4181 lines: 
https://github.com/dlang/phobos/blob/master/std/path.d

Documentation: https://dlang.org/phobos/std_path.html

It's over an order of magnitude more code and only takes twice as 
long to compile without unittests, and it's only fair to compare 
the "non-unittest" version of std.path with Go, since Go does not 
include unittests.


I'm not sure why you would compile the standard library unittests 
every time you compile anything. Probably a consequence of not 
having `-unittest=`.  timotheecour suggested we add 
support for this and I agree for cases like this, where druntime 
and phobos would be exclude by default (just like we do with -i), 
meaning that your compilation example would not have compiled 
phobos unittests.

Feature request: Support for 512 bit vectors in core smid, for avx2

[12345swordy via Digitalmars-d]

The dmd compiler curretnly accepts avx2 cpu flag, surely it 
shouldn't be to hard to  create a 16int vector?


-Alex

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 15:49:30 UTC, jmh530 wrote:

On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote:

[snip]



Doesn't extend to multiple template parameters that well...
[snip]


This works, but ugly...

template testFunction(T, U = TestAlias!T, alias V = 
TemplateOf!(U), W = TemplateArgsOf!U[1])

{
void testFunction(V!(T, W) arg) {}
}

Re: D compiles fast, right? Right??

[Meta via Digitalmars-d]

On Friday, 30 March 2018 at 16:12:44 UTC, Atila Neves wrote:
Fast code fast, they said. It'll be fun, they said. Here's a D 
file:


import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

/tmp % time dmd -c  foo.d
dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


That... doesn't seem too fast to me. But wait, there's more:

/tmp % time dmd -c -unittest foo.d
dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 
0.525 total



Half. A. Second. AKA "an eternity" in dog years, err, CPU time. 
I know this has been brought up before, and recently even, but, 
just... just... sigh.


So I wondered how fast it'd be in Go, since it's got a 
reputation for speedy compilation:


package foo
import "path"
func Foo() string {
return path.Base("foo")
}

/tmp % time go tool compile foo.go
go tool compile foo.go  0.01s user 0.01s system 117% cpu 
0.012 total



See, now that's what I'd consider fast. It has actual code in 
the file because otherwise it complains the file isn't using 
the imported package, because, Go things. It compiled so fast I 
had to check I'd generated an object file, and then I learned 
you can't use objdump on Go .o files, because... more Go things 
(go tool objdump for the curious).


Ok, so how about C++, surely that will make D look good?

#include   // yes, also a one-liner

/tmp % time /usr/bin/clang++ -std=c++17 -c foo.cpp
/usr/bin/clang++ -std=c++17 -c foo.cpp  0.45s user 0.03s 
system 96% cpu 0.494 total


/tmp % time /usr/bin/g++ -std=c++17 -c foo.cpp
/usr/bin/g++ -std=c++17 -c foo.cpp  0.39s user 0.04s system 
99% cpu 0.429 total



So yeeah. If one is compiling unit tests, which I 
happen to pretty much only exclusively do, then trying to do 
anything with paths in D is


1. Comparable to C++ in build times
2. Actually _slower_ than C++ (who'd've thunk it?) *
3. Gets lapped around Captain America vs The Falcon style about 
50 times by Go.


And that's assuming there's a crazy D programmer out there 
(hint: me) that actually tries to compile minimal units at a 
time (with actual dependency tracking!) instead of the whole 
project at once, otherwise it'll take even longer. And this to 
just import `std.path`, then there's the actual work you were 
trying to get to.


Today actually made me want to write Go. I'm going to take a 
shower now.


Atila

* Building a whole project in C++ still takes a lot longer 
since D scales much better, but that's not my typical worflow, 
nor should it be anyone else's.


Yeah, that's pretty bad, relatively, for a no-op build. Probably 
some CTFE or template stuff that gets pulled in by one of the 
imports.

D compiles fast, right? Right??

[Atila Neves via Digitalmars-d]

Fast code fast, they said. It'll be fun, they said. Here's a D 
file:


import std.path;


Yep, that's all there is to it. Let's compile it on my laptop:

/tmp % time dmd -c  foo.d
dmd -c foo.d  0.12s user 0.02s system 98% cpu 0.139 total


That... doesn't seem too fast to me. But wait, there's more:

/tmp % time dmd -c -unittest foo.d
dmd -c -unittest foo.d  0.46s user 0.06s system 99% cpu 0.525 
total



Half. A. Second. AKA "an eternity" in dog years, err, CPU time. I 
know this has been brought up before, and recently even, but, 
just... just... sigh.


So I wondered how fast it'd be in Go, since it's got a reputation 
for speedy compilation:


package foo
import "path"
func Foo() string {
return path.Base("foo")
}

/tmp % time go tool compile foo.go
go tool compile foo.go  0.01s user 0.01s system 117% cpu 
0.012 total



See, now that's what I'd consider fast. It has actual code in the 
file because otherwise it complains the file isn't using the 
imported package, because, Go things. It compiled so fast I had 
to check I'd generated an object file, and then I learned you 
can't use objdump on Go .o files, because... more Go things (go 
tool objdump for the curious).


Ok, so how about C++, surely that will make D look good?

#include   // yes, also a one-liner

/tmp % time /usr/bin/clang++ -std=c++17 -c foo.cpp
/usr/bin/clang++ -std=c++17 -c foo.cpp  0.45s user 0.03s 
system 96% cpu 0.494 total


/tmp % time /usr/bin/g++ -std=c++17 -c foo.cpp
/usr/bin/g++ -std=c++17 -c foo.cpp  0.39s user 0.04s system 
99% cpu 0.429 total



So yeeah. If one is compiling unit tests, which I 
happen to pretty much only exclusively do, then trying to do 
anything with paths in D is


1. Comparable to C++ in build times
2. Actually _slower_ than C++ (who'd've thunk it?) *
3. Gets lapped around Captain America vs The Falcon style about 
50 times by Go.


And that's assuming there's a crazy D programmer out there (hint: 
me) that actually tries to compile minimal units at a time (with 
actual dependency tracking!) instead of the whole project at 
once, otherwise it'll take even longer. And this to just import 
`std.path`, then there's the actual work you were trying to get 
to.


Today actually made me want to write Go. I'm going to take a 
shower now.


Atila

* Building a whole project in C++ still takes a lot longer since 
D scales much better, but that's not my typical worflow, nor 
should it be anyone else's.

Re: std.variant Is Everything Cool About D

[Meta via Digitalmars-d-announce]

On Friday, 30 March 2018 at 13:44:50 UTC, Meta wrote:
I've submitted it to Hacker News as well (looks like someone 
posted it yesterday, but it only got 1 vote and there was no 
discussion, so I figured that was grounds enough for 
resubmission). If you've got an account, please give me your 
meaningless internet points.


https://hn.algolia.com/?query=std.variant%20is%20everything%20cool%20about%20d=byDate=0=custom=story=1522368000=1522454400


And it seems they're still not biting. Looking at the front page, 
I can't believe how few actual programming or startup-related 
submissions there are.


https://imgur.com/a/hFlbs

Re: #dbugfix Issue 16486 200$

[Rubn via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

Hello,

Bugfix for the Issue 16486 [1] (originally [2]) is required for 
mir-algorithm types [3], [4].


For example, packed triangular matrix can be represented as

Slice!(Contiguous, [1], StairsIterator!(T*))
Slice!(Contiguous, [1], 
RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))


They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


Workarounds aren't interesting.

200$  - bounty ( I can pay directly or transfer money to the 
Dlang Foundation )


Best Regards,
Ilya Yaroshenko

[1] https://issues.dlang.org/show_bug.cgi?id=16486
[2] https://issues.dlang.org/show_bug.cgi?id=16465
[3] 
http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice

[4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
[5] 
https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d


It's a feature request, according to the comments. So before 
anyone goes wasting their time implementing this. Someone might 
want to write the DIP for it.

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote:

[snip]



Doesn't extend to multiple template parameters that well...

import std.traits : TemplateOf;

struct TestType(T, U) {}
alias TestAlias(T) = TestType!(T, int);

template testFunction(T, alias U = TemplateOf!(TestAlias!T))
{
void testFunction(U!(T, int) arg) {} //don't want to have to 
put the int here

}

void main()
{
TestAlias!int testObj;
testFunction(testObj);
}

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote:

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[1] https://issues.dlang.org/show_bug.cgi?id=16486



Ah that is an interesting bug which further demonstrates that 
templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just 
forwards to another.

Therefore you have to create separate types.
And since you create separate types the alias is not an alias 
but a separate template.
Solving this may be possible for special cases but in the 
general case is infeasible.


What about something like this (using the reduced example from 
the bug report):


import std.traits : TemplateOf;

struct TestType(T) {}
alias TestAlias(T) = TestType!T;

template testFunction(T, alias U = TemplateOf!(TestAlias!T))
{
void testFunction(U!T arg) {}
}

void main()
{
TestAlias!int testObj;
testFunction(testObj);
}

Re: #dbugfix Issue 16486 200$

[Timon Gehr via Digitalmars-d]

On 30.03.2018 08:11, 9il wrote:

Hello,

Bugfix for the Issue 16486 [1] (originally [2]) is required for 
mir-algorithm types [3], [4].


For example, packed triangular matrix can be represented as

Slice!(Contiguous, [1], StairsIterator!(T*))
Slice!(Contiguous, [1], 
RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))


They are used in mir-lapack [5]. The bug fix also required for mir 
(Sparse, CompressedTensor), and for the future Dlang image library.


Workarounds aren't interesting.

200$  - bounty ( I can pay directly or transfer money to the Dlang 
Foundation )


Best Regards,
Ilya Yaroshenko

[1] https://issues.dlang.org/show_bug.cgi?id=16486
[2] https://issues.dlang.org/show_bug.cgi?id=16465
[3] http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice
[4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
[5] https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d


This is supported in https://github.com/tgehr/d-compiler
It has explicit "unknown" types and may instantiate templates using them 
during IFTI. The result is then matched against the argument types.

Re: dynamically compile and load glue logic

[rikki cattermole via Digitalmars-d-learn]

On 31/03/2018 3:38 AM, H. S. Teoh wrote:

On Fri, Mar 30, 2018 at 02:24:45PM +, yawniek via Digitalmars-d-learn wrote:

in how far is it or would the following be possible:

dynamically compile and execute some glue logic that is also written
in D under linux?

and what happens if that code uses phobos or other dub libs that are
available in the host binary?

[...]

I've written a program where user input drives the generation of a code
snippet that then gets passed to an invocation of dmd, compiled, linked
and the loaded as a shared library via dlopen(), et al. It works fairly
well, and dmd generally is fast enough that the pause is not very
noticeable. (This was before dmd-as-a-library was available; I imagine
it would be even faster today now that you don't have to spawn a
separate dmd process.)


Still need to, front end is barely alpha.
Can't be reset for example (last I checked, but doubt that has changed).

Re: dynamically compile and load glue logic

[H. S. Teoh via Digitalmars-d-learn]

On Fri, Mar 30, 2018 at 02:24:45PM +, yawniek via Digitalmars-d-learn wrote:
> in how far is it or would the following be possible:
> 
> dynamically compile and execute some glue logic that is also written
> in D under linux?
> 
> and what happens if that code uses phobos or other dub libs that are
> available in the host binary?
[...]

I've written a program where user input drives the generation of a code
snippet that then gets passed to an invocation of dmd, compiled, linked
and the loaded as a shared library via dlopen(), et al. It works fairly
well, and dmd generally is fast enough that the pause is not very
noticeable. (This was before dmd-as-a-library was available; I imagine
it would be even faster today now that you don't have to spawn a
separate dmd process.)

The generated snippet does import std.math, and it seems to work fine.
But then the generated snippets tend to be fairly small, and only use a
limited subset of the language, so there may be gotchas that I'm not
aware of.


T

-- 
Don't throw out the baby with the bathwater. Use your hands...

dynamically compile and load glue logic

[yawniek via Digitalmars-d-learn]

in how far is it or would the following be possible:

dynamically compile and execute some glue logic that is also 
written in D under linux?


and what happens if that code uses phobos or other dub libs that 
are available in the host binary?


especially the 2nd point is important as i would want to load 
100's of those snippets.


For the context: the idea is to create a streaming-ETL system 
where you can dynamically add/remove rules/modules. it would be 
great if logic could be written directly in D and operate on 
specific (library provided) objects.

Re: #dbugfix Issue 16486 200$

[Stefan Koch via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

[1] https://issues.dlang.org/show_bug.cgi?id=16486



Ah that is an interesting bug which further demonstrates that 
templates are a tricky thing :)
Basically you cannot _generally_ proof that one template just 
forwards to another.

Therefore you have to create separate types.
And since you create separate types the alias is not an alias but 
a separate template.
Solving this may be possible for special cases but in the general 
case is infeasible.

Re: #dbugfix Issue 16486 200$

[jmh530 via Digitalmars-d]

On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote:

Hello,

Bugfix for the Issue 16486 [1] (originally [2]) is required for 
mir-algorithm types [3], [4].


For example, packed triangular matrix can be represented as

Slice!(Contiguous, [1], StairsIterator!(T*))
Slice!(Contiguous, [1], 
RetroIterator!(MapIterator!(StairsIterator!(RetroIterator!(T*)), retro)))


They are used in mir-lapack [5]. The bug fix also required for 
mir (Sparse, CompressedTensor), and for the future Dlang image 
library.


Workarounds aren't interesting.

200$  - bounty ( I can pay directly or transfer money to the 
Dlang Foundation )


Best Regards,
Ilya Yaroshenko

[1] https://issues.dlang.org/show_bug.cgi?id=16486
[2] https://issues.dlang.org/show_bug.cgi?id=16465
[3] 
http://docs.algorithm.dlang.io/latest/mir_ndslice_slice.html#Slice

[4] http://docs.algorithm.dlang.io/latest/mir_series.html#Series
[5] 
https://github.com/libmir/mir-lapack/blob/master/source/mir/lapack.d


Given the recent blog post on std.variant, it occurs to me that 
this enhancement would also make writing functions that take 
Option types much easier. I'm adopting some of the code from the 
blog post below:


import std.variant;

alias Null = typeof(null); //for convenience
alias Option(T) = Algebraic!(T, Null);

Option!size_t indexOf(int[] haystack, int needle) {
foreach (size_t i, int n; haystack)
if (n == needle)
return Option!size_t(i);
return Option!size_t(null);
}

auto foo(T)(VariantN!(T.sizeof, T, typeof(null)) x)
{
return x;
}

auto bar(T : Option!U, U)(T x)
{
return x;
}

auto baz(T)(Option!T x)
{
return x;
}

void main()
{
import std.stdio : writeln;

int[] a = [4, 2, 210, 42, 7];
Option!size_t index = a.indexOf(42);

writeln(index.foo!size_t); //works
//writeln(index.foo); //doesn't work
//writeln(index.bar); //doesn't work
//writeln(index.baz); //doesn't work
}

Re: std.variant Is Everything Cool About D

[Meta via Digitalmars-d-announce]

On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote:
Jared Hanson (a.k.a Meta and MetaLang around these parts) was 
inspired by an article titled "std::visit is everything wrong 
with modern C++" to contrast it with D's std.variant.visit. The 
result is this well-written post for the D Blog.


The blog:
https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/

Reddit:
https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/


I've submitted it to Hacker News as well (looks like someone 
posted it yesterday, but it only got 1 vote and there was no 
discussion, so I figured that was grounds enough for 
resubmission). If you've got an account, please give me your 
meaningless internet points.


https://hn.algolia.com/?query=std.variant%20is%20everything%20cool%20about%20d=byDate=0=custom=story=1522368000=1522454400

Re: IFTI for constructors worth a DIP?

[Steven Schveighoffer via Digitalmars-d]

On 3/30/18 2:25 AM, Dmitry Olshansky wrote:

On Friday, 30 March 2018 at 06:21:27 UTC, Dmitry Olshansky wrote:
I think it should be mostly stright-forward and we can get rid of 
“instantiator” functions to do IFTI.


The problem (I guess) is 2 type parameter lists, one of aggregate and 
the other of function:


struct Foo(T)
if (isSomeSuch!T)
{
    this(U)(T a, U u) if (isSomethindElse!U) {...}
    this(R)(T x, R r) if (yetAnother!U){ ... }
}


More interesting case...
struct Foo(T)
{
  alias K = T.K;
  this(K k) {  }
  // same
}

In general it might be impossible (if we throw in more static ifs on T’s 
type) but well IFTI is not 100% solution anyway.




I believe in such a case compiler can as far as IFTI goes just 
consider a combined tuple of types.


Thoughts?





The easy way to test these is to see what IFTI does now:

import std.traits;

template foo(T)
if (isIntegral!T)
{
void foo(U)(T a, U u) if (isSomeString!U) {}
}

void main()
{
foo(1, "hello");
}

onlineapp.d(11): Error: template onlineapp.foo cannot deduce function 
from argument types !()(int, string), candidates are:

onlineapp.d(3):onlineapp.foo(T) if (isIntegral!T)

Your second case:

struct Foo(T)
{
 alias K = T.K;
 this(K k) {  }
 // same
}

I can't see at all how this would work, as there may be infinite types 
for T that have an alias K that matches.



However, a simpler case:

template foo(T)
{
 alias K = T;
 void foo(K k) {}
}

void main()
{
foo(1);
}

onlineapp.d(4): Error: undefined identifier K
onlineapp.d(10): Error: template onlineapp.foo cannot deduce function 
from argument types !()(int), candidates are:

onlineapp.d(1):onlineapp.foo(T)(K k)

So it appears IFTI wouldn't be up to the task if there are aliases 
involved, or nested templates. But the simplest cases it does work with:


import std.traits;

template foo(T, U)
if (isIntegral!T && isSomeString!U)
{
void foo(T a, U u) {}
}

void main()
{
foo(1, "hello");
}

A class/struct ctor (where the constructor itself isn't a template) 
isn't any different, I can't see why it wouldn't work.


-Steve

Re: How to use chromium embedded framework in dlang ?

[JN via Digitalmars-d]

On Thursday, 29 March 2018 at 19:09:47 UTC, Jayam wrote:
How to create desktop application using chromium embedded 
framework in dlang


Not sure how up to date is it, but you can give 
https://github.com/DerelictOrg/DerelictCEF a go.

Re: std.variant Is Everything Cool About D

[rjframe via Digitalmars-d-announce]

On Fri, 30 Mar 2018 00:55:20 +, dangbinghoo wrote:

> I think we need a book about D's std Phobos, like `mastering STL`
> or something like C++ world do, but of course, I didn't mean selling to
> C++ world, I mean newbie may need knowledge about the Phobos and the
> design and using the power of the library for real practice, not to
> compare with the C++ world.

I'm not sure Phobos is complex enough to need a book just for the library. 
Anything that would go into it would either be a programming in
D-in-general thing or would be a useful improvement to the documentation 
itself.

[Issue 18697] core.sys.posix.strings is missing

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com

--

[Issue 18697] core.sys.posix.strings is missing

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

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

--- Comment #1 from John Colvin  ---
Sorry, correct link:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/strings.h.html

--

[Issue 18697] New: core.sys.posix.strings is missing

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

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

  Issue ID: 18697
   Summary: core.sys.posix.strings is missing
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

See http://pubs.opengroup.org/onlinepubs/9699919799/

--

Re: Initializing a class member that is an object

[Laurent Tréguier via Digitalmars-d-learn]

On Friday, 30 March 2018 at 11:14:32 UTC, ketmar wrote:
please, make an ER in bugzilla then. 'cause it will be lost 
here, and with ER we have a chance to eventually do that.


Will do.

Re: Initializing a class member that is an object

[ketmar via Digitalmars-d-learn]

Laurent Tréguier wrote:


On Friday, 30 March 2018 at 11:04:59 UTC, ketmar wrote:
p.s.: still, it may be nice to warn user about that. 'cause such runtime 
initializations are really belong to static ctor. dunno, i'm ok both 
with warning and without it.


I simply think a word about it in the docs would be nice, since this is 
tricky if you come from another language that doesn't do this. Otherwise 
I'm fine with it (and it's not exactly hard to fix either)


please, make an ER in bugzilla then. 'cause it will be lost here, and with 
ER we have a chance to eventually do that.

Re: Initializing a class member that is an object

[Laurent Tréguier via Digitalmars-d-learn]

On Friday, 30 March 2018 at 11:04:59 UTC, ketmar wrote:
p.s.: still, it may be nice to warn user about that. 'cause 
such runtime initializations are really belong to static ctor. 
dunno, i'm ok both with warning and without it.


I simply think a word about it in the docs would be nice, since 
this is tricky if you come from another language that doesn't do 
this. Otherwise I'm fine with it (and it's not exactly hard to 
fix either)

Re: Link-time optimisation (LTO)

[Johan Engelen via Digitalmars-d-learn]

On Friday, 30 March 2018 at 10:23:15 UTC, Cecil Ward wrote:
Say that I use say GDC or LDC. I want to declare a routine as 
public in one compilation unit (.d src file) and be able to 
access it from other compilation units.


Do I simply declare the routine with the word keyword public 
before the usual declaration?


Or maybe that is the default, like not using the keyword static 
with function declarations in C?


Global functions in a module have default "public" visibility 
indeed.

https://dlang.org/spec/attribute.html#visibility_attributes

My principal question: If I successfully do this, with GCC or 
LDC, will I be able to get the code for the externally defined 
short routine expanded inline and fully integrated into the 
generated code that corresponds to the calling source code? (So 
no ‘call’ instruction is even found.)


What you want is "cross-module inlining".
As far as I know, DMD and GDC will do cross-module inlining (if 
inlining is profitable).


LDC does not, unless `-enable-cross-module-inlining` is enabled 
(which is aggressive and may result in linking errors in specific 
cases, https://github.com/ldc-developers/ldc/pull/1737).
LDC with LTO enabled will definitely give you cross-module 
inlining (also for private functions).


You can force inlining with `pragma(inline, true)`, but it is 
usually better to leave that decision up to the compiler.

https://dlang.org/spec/pragma.html#inline

-Johan

Re: Initializing a class member that is an object

[ketmar via Digitalmars-d-learn]

p.s.: still, it may be nice to warn user about that. 'cause such runtime 
initializations are really belong to static ctor. dunno, i'm ok both with 
warning and without it.

Re: Initializing a class member that is an object

[ketmar via Digitalmars-d-learn]

Laurent Tréguier wrote:


Is this behavior really intentional ?
yes. default values should be the same for all objects. it is predictable, 
and allows to initialize objects to the known state simply by blitting 
`.init`.


that is, default values aren't a syntax sugar for defining implicit ctor 
actions, they are executed once. this is by design.

Re: dmd segmentation fault with duplicate class definition

[LiNbO3 via Digitalmars-d]

On Thursday, 29 March 2018 at 21:18:02 UTC, Seb wrote:

On Thursday, 29 March 2018 at 20:48:47 UTC, number wrote:
I'm learning, so no idea if this is known or what causes the 
segfault.


[...]


Always try the latest release when you run into an ICE - 
chances are very good that it already has been fixed:


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


There are a couple of bugs here:

---
void main()
{
{ class C { } }
class C { }
// C x; x.x=1;
// static assert (!__traits(compiles, C.x));
}
---

The first bug can be shown by de-commenting the first line and 
can be easily solved by modifying hdrgen.d by adding a check on 
t.sym.parent being non-null to the visit(TypeClass) method.
Once that's fixed de-comment the second line to have the compiler 
crash and burn somewhere else.

Re: Building application with LDC and -flto=thin fails in link stage

[Johan Engelen via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 16:42:23 UTC, Johan Engelen wrote:

On Tuesday, 27 March 2018 at 22:10:33 UTC, Per Nordlöw wrote:

On Tuesday, 27 March 2018 at 22:00:42 UTC, Johan Engelen wrote:

Indeed.
Please try to manually link first (without dub) by modifying 
the command on which dub errors:


```
ldmd2 -flto=thin 
-of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2

```

-Johan


Yes, that works!


I'm no dub expert and I don't know how to pass flags to the 
_compiler_ for the link step.

Would be good to figure that out with the dub folks.


For a stopgap solution:
I think what you are doing is passing 
`--compiler=/ldmd2` (note: LDMD) to dub when building, 
and you get separate compilation+linking. If you'd use 
`--compiler=/ldc2` (note: LDC), then you would not get 
separate compilation+linking [1] and things work with just 
setting `dflags`.


I've asked about the problem here: 
https://github.com/dlang/dub/issues/1431


cheers,
  Johan

[1] https://github.com/dlang/dub/issues/809

Initializing a class member that is an object

[Laurent Tréguier via Digitalmars-d-learn]

Coming from a more Java-esque background, I'm used to sometimes 
initializing class members outside of the constructor :


class MyClass {
Object member = new Object();
}

I've tried using this in D, but I've come to realize it acts very 
differently. In Java, the `new Object()` will be executed every 
time a new `MyClass` object is instantiated. In D however, it 
seems to be executed once, and members of every `MyClass` object 
will then be initialized with a reference to that one unique 
`Object`.


Example: https://run.dlang.io/is/Qlx2xY

Is this behavior really intentional ? I don't really see how it 
could be useful, and it's really confusing at first to see new 
objects with weird values even if none of their members has been 
touched yet...

Re: Building application with LDC and -flto=thin fails in link stage

[Johan Engelen via Digitalmars-d-learn]

On Thursday, 29 March 2018 at 08:44:21 UTC, Jacob Carlborg wrote:


Please read the reply :), although it could be a bit more clear.


I'll spell it out for you.

Both `dflags` and `lflags` are being used already. With separate 
compilation and linking, there seems to be no way to pass flags 
to the compiler during the linking step: dflags is not used and 
lflags is prefixed with `-L`.


-Johan

Link-time optimisation (LTO)

[Cecil Ward via Digitalmars-d-learn]

Say that I use say GDC or LDC. I want to declare a routine as 
public in one compilation unit (.d src file) and be able to 
access it from other compilation units.


Do I simply declare the routine with the word keyword public 
before the usual declaration?


Or maybe that is the default, like not using the keyword static 
with function declarations in C?


My principal question: If I successfully do this, with GCC or 
LDC, will I be able to get the code for the externally defined 
short routine expanded inline and fully integrated into the 
generated code that corresponds to the calling source code? (So 
no ‘call’ instruction is even found.)

Re: dmd segmentation fault with duplicate class definition

[number via Digitalmars-d]

On Thursday, 29 March 2018 at 21:18:02 UTC, Seb wrote:

On Thursday, 29 March 2018 at 20:48:47 UTC, number wrote:
I'm learning, so no idea if this is known or what causes the 
segfault.


[...]


Always try the latest release when you run into an ICE - 
chances are very good that it already has been fixed:


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


the provoking line is commented out in that snippet. when 
commented in, all compilers give the segfault, including ldc 
ones. except for 'all dmd compilers..' with version <= 2.066.0

Re: rvalues -> ref (yup... again!)

[Kagamin via Digitalmars-d]

On Wednesday, 28 March 2018 at 16:15:53 UTC, Manu wrote:
I discussed that in that document. I'm happy to remove const, 
but it requires a value judgement on the meaning of non-const 
in this case. It becomes controversial without const, but I'm 
personally happy to remove it if you can make The argument in 
favour. Can you give me some ideas where it would be useful?


doesn't make sense because the output would be immediately 
discarded; such a function call given an rvalue as argument 
likely represents an accidental mistake on the users part, and 
we can catch that invalid code.


Most obvious:

void Close(ref HANDLE h)
{
  CloseHandle(h);
  h=INVALID_HANDLE;
}

If you want to take input argument, then of course mark it as 
input, but if not then not. Why the callee would need to care if 
the argument is rvalue or not? The only criticism against rvalue 
references I saw was when the reference outlives the temporary.

[Issue 18689] std.format should always throw FormatException on bad specs/arguments

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

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

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

https://github.com/dlang/phobos/commit/e2d791bcf1c2a129ec988589b7cabc9c65721dde
Fix Issue 18689 - std.format should throw FormatException on bad format spec

--

[Issue 18604] in parameter storage class should be deprecated

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

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

--- Comment #7 from anonymous4  ---
Another possibility is -transition=in flag that will deprecate `in` on demand,
and after people remove usage of `in` storage class from their code, it can
start enforce `scope const` meaning.

--

Re: std.variant Is Everything Cool About D

[Patrick Schluter via Digitalmars-d-announce]

On Friday, 30 March 2018 at 03:54:21 UTC, Mike Parker wrote:

On Friday, 30 March 2018 at 02:46:13 UTC, jmh530 wrote:

On Friday, 30 March 2018 at 00:37:27 UTC, Meta wrote:


Unfortunately, this turned out to be the worst possible day 
for me to try to actively monitor the thread and respond to 
questions. I'm surprised that people latched onto my little 
quip about C++ using the name variant for a tagged union.


It seems that any comment in a D article that refers to C++ 
will be construed in the worst possible way on reddit...


That's fine by me. Right now, this post is the fourth 
most-viewed this year and it's not far off from number three.


While I would love to please the reddit crowd to the extent 
that we see no negativity, I'm quite happy with the fact that 
our comment threads there are nowhere near as negative as they 
used to be. Posts that do generate this level of discussion 
have higher views.


I can't dismiss reddit comments completely, but I don't put as 
much weight on them as I used to. A subreddit is somewhat 
comparable to a forum for a popular video game -- lots of vocal 
people who are actually a small minority of the player base. We 
can't measure the number of people who click the reddit link to 
the blog and come away from it with a positive impression. They 
aren't going to bother commenting on reddit.


You're right and the unreasonable position of the 
SolidStateGraphics user is clear for everyone to see. There are 
some points he makes that could be discussed but by holding 
essentially the position "D is shit because it is not C++" his 
whole argumentation falls apart as Stockholm-syndrome induced 
rationalisation.

Re: rvalues -> ref (yup... again!)

[Atila Neves via Digitalmars-d]

On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote:
On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d 
 wrote:

On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote:


On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d 
 wrote:


On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote:





That's _if_ T is big and _if_ it even gets copied,


You've just described the exact anatomy of a ref function!
You wouldn't write a function to receive T by ref UNLESS T was 
both
big, and the function probably won't inline (therefore 
definitely
copy), and that condition will be triggered by any of the list 
of
reasons I've said a bunch of times (extern, dll, lib, virtual, 
etc).
People don't just love writing ref (well, some people might), 
but they
use it deliberately, typically in user-facing boundary API's 
for these

exact reasons.


I know. I was arguing that those cases are uncommon and the API 
pain is therefore not too big of an issue. I'm pretty sure that 
you feel it more because of what you write in D.



Right. I'm talking about deliberate use of ref... Or *existing*
(deliberate) use of ref, as is the case in almost all my my 
cases. The

code already exists.


Right, and I was assuming (perhaps incorrectly) that this 
existing code was C++, hence me being on board with binding 
rvalues to const ref there.


Only if you ARE moving, and not copying. D must deep copy too 
if you

actually copy.
Your example assumes C++ doesn't have a move constructor. D has
implicit move semantics, so you can only make an equivalent 
comparison
where C++ also defines the move constructor so the move case 
doesn't

pollute the ref comparison.


I wasn't assuming the lack of a move constructor. What I was 
saying is that passing by value in C++ will usually mean a copy, 
whereas in D it usually means a move.


Also, irrespective of whether move semantics are performed 
(eliding
potential deep copying, as in your example), the binary memcpy 
still
has to be performed when handling values by-val, unless RVO 
(we're not
talking about return values), or inlining is able to eliminate 
it.


Good point about memcpy.

In C++'s case, it's not that references were deficient at 
being references that C++ needed rval-references, it's that 
references were deficient at being move-able.



There were deficient at being moveable because temporaries can 
bind to const T&.


... what? That's just not true at all.
If temporaries couldn't bind to C++ ref, then you *definitely*
wouldn't be able to move it, because you can guarantee that 
someone

else owns the reference.


Precisely. That's how D works.


rvalue references were introduced in C++ to capture the calls 
with
rvalues into a separate function call, exactly the same way as 
the
by-value overload will catch the rvalues in D (and perform an 
implicit

move).


Yes.

It was impossible for C++ to implement D's implicit move 
semantics

when receiving by-value for reasons that have nothing to do with
references; C++ allows interior pointers which breaks implicit 
moving,
C++ can overload default constructor which also breaks implicit 
moving

(no implicit way to reset the state of the prior owner).


I hadn't thought about the implications of interior pointers. 
Very good point.



References have no interaction with move semantics.


Even given interior pointers, I disagree.

But again, we're not talking about move semantics here, we're 
just talking about references ;)


See comment above ;)


I'd love to know what that would look like.


That's exactly what I've been saying. For like, 9 years..
It looks like this:
https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
 (contribution appreciated)


I was unaware of this (or I forgot). After reading it I'm not 
sure of what corner cases might arise, but if I'm getting it 
right I think it could work.



And as far as I
can tell, it basically only affects me, because I do so much 
work

against established C++ code! >_<


That's entirely possible. I can use my fingers to count the 
number of times I've written `extern(C++)`.


Atila

[Issue 16037] assigning delegate to a scope variable shouldn't allocate closure

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

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

--- Comment #11 from anonymous4  ---
(In reply to Mathias Lang from comment #9)
> So I strongly oppose gratuitous breakage of code (breakage with does not
> come with a deprecation)
You want usage of `scope` storage class be reported as deprecated? Would
-transition=scope flag be good enough for it?

--

[Issue 17670] Std.bitmanip module has no (runnable) examples

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #2 from Seb  ---
Fixed with

https://github.com/dlang/phobos/pull/6374
https://github.com/dlang/phobos/pull/6343
https://github.com/dlang/phobos/pull/6344

--

[Issue 18696] New: runnable/test18322.d is failing spuriously on Win32

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

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

  Issue ID: 18696
   Summary: runnable/test18322.d is failing spuriously on Win32
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

>From the auto-tester:

---
 ... runnable\test18322.d   -Irunnable/imports   ()
Test runnable/test18322.d failed.  The logged output:
..\generated\windows\release\32\dmd.exe -conf= -m64 -Irunnable
-Irunnable/imports   -L/OPT:NOICF  -odtest_results\runnable
-oftest_results\runnable\test18322_0.exe  runnable\test18322.d
runnable/imports/test18322import.d -map nul.map


test_results\runnable\test18322_0.exe

..\generated\windows\release\32\dmd.exe -conf= -m64 -Irunnable
-Irunnable/imports   -L/OPT:NOICF  -odtest_results\runnable
-oftest_results\runnable\test18322_0.exe  runnable\test18322.d -i -map nul.map

LINK : fatal error LNK1104: cannot open file
'test_results\runnable\test18322_0.exe'
Error: linker exited with status 1104
---

--

[Issue 18670] compiler segfault if `new` on a union type with dip1000

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #7 from RazvanN  ---
Fixed in stable : https://github.com/dlang/dmd/pull/8095

--

[Issue 18581] Segmentation fault with dmd -X if static foreach inside template

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

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

Seb  changed:

   What|Removed |Added

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

--

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Dmitry Olshansky via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 23:25:09 UTC, Walter Bright wrote:

On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
There's usually nothing that prevents the build tool to write 
files at build time. Dub can do this.


It's expected with a build tool. Not a compiler.


With the frame of mind prevalent in our Industry I really want to 
have compiler includibg codegen as a bunch of library components.


Then there is no problem innovating while people argue over 
things “allowed” for a compiler, or a linker, or a build tool. 
None of these actually have to be apps talking via files.


If I look closely every program I see is a graph database, with 
nodes sometimes being code, types, sometimes data, other 
meta-data such as ABI attributes or conditional compilation 
flags, documentation, external tools, specs and databases are 
also part of this. Code that produces code is also part of such 
graph, and CTFE/macroses would just be finer grained approach.


Why process graphs piece-wise in a frentic dance of command-line 
tools that try to fit all to a tree of files (multiple ones, in 
many location, and part in some CMS) and then have editors/IDEs 
integrate? Was easier I believe + inertia, easy != simple though.

[Issue 9497] ddoc: add support for handling undefined macros

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

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |FIXED

--- Comment #4 from Seb  ---
This was fixed in https://github.com/D-Programming-Language/dmd/pull/1653
(though someone didn't get closed) -> closing.

BTW we now even have a check in place for dlang.org that prevents the usage of
undefined macros.

--

[Issue 14099] Promote DPaste (dpaste.dzfl.pl) to run.dlang.org

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #11 from Seb  ---
> Maybe we should seriously consider compartmentalizing (e.g. using Docker) ALL 
> our services, so they can be moved around on a whim as needed. 

Yes please. It makes local testing, reproduction and migration really easy.

FYI: run.dlang.io is an docker image which gets built and pushed to Dockerhub.
Now if the server that runs run.dlang.io crashes one day, it's in theory as
easy as "docker run" on a new server (in practice, there's Nginx config + SSL +
local config, but it could be a lot worse).

> This is a proposal to make it officially a part of dlang.org: promote the 
> website to run.dlang.org, and add a link to it on the D website (e.g. under 
> the "Resources" submenu). The source code can be made publicly available if 
> necessary.

-> https://github.com/dlang/dlang.org/pull/2312

> I'm all for increasing the bus factor, but is the situation with Jan much 
> different?
> ...
> I can start by setting up a mirror for dlang.org. And, done! Just point 
> dlang.org to k3.1azy.net in the event it's needed. You already have shell 
> access to update it.

This now got worse as there's dlang.org/blog + dlang.org/lists, because in the
event of a downtime, you can simple copy/paste the snapshot from
https://docarchives.dlang.io/v2.079.0

--

[Issue 4591] Concat of std.typecons.Tuples

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

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
https://github.com/dlang/phobos/pull/6386

--

Re: IFTI for constructors worth a DIP?

[Dmitry Olshansky via Digitalmars-d]

On Friday, 30 March 2018 at 06:21:27 UTC, Dmitry Olshansky wrote:
I think it should be mostly stright-forward and we can get rid 
of “instantiator” functions to do IFTI.


The problem (I guess) is 2 type parameter lists, one of 
aggregate and the other of function:


struct Foo(T)
if (isSomeSuch!T)
{
this(U)(T a, U u) if (isSomethindElse!U) {...}
this(R)(T x, R r) if (yetAnother!U){ ... }
}


More interesting case...
struct Foo(T)
{
 alias K = T.K;
 this(K k) {  }
 // same
}

In general it might be impossible (if we throw in more static ifs 
on T’s type) but well IFTI is not 100% solution anyway.




I believe in such a case compiler can as far as IFTI goes just 
consider a combined tuple of types.


Thoughts?

[Issue 14637] Array operations should work on tuples

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

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #6 from Seb  ---
PR https://github.com/dlang/phobos/pull/6386

--