Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 04:50 PM, Ali Çehreli wrote:


My off-topic contribution to this thread: I won't be surprised when C++
will eventually be classified as a case of mass hysteria.



That'll happen at the same time modern web technology stacks are 
classified similarly.


Much as I'd love to see that day, I'm not holding my breath...

But seriously, every time I look at anything going on in C++ the last 
several years, it looks more and more like it just simply wants to *be* 
D, takes a couple drunken steps in that direction, and falls flat on its 
face.

Re: gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 05:13 PM, Iain Buclaw via Digitalmars-d wrote:

On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d


The last GDC release is stuck all the way back at DMDFE v2.066, which is
over two years old. Very few libs/projects are going to still be supporting
that, there's just too much limitation going back that far. LDC had been
keeping up much better.



...

And GDC is using the 2.068 feature set, plus a lot of bug fixes from
later versions.  I guess you could call it 2.068.5.  :-)



Maybe there's a certain amount of truth to that, but not completely: In 
all my projects anyway, the latest available GDC on travis always broke 
at exactly the same time DMD 2.066 and below broke. I don't think I have 
any remaining projects that still work on GDC, but several still work on 
DMD 2.067.1 (not sure about 2.067.0, don't use that one in my 
.travis.yml files since 2.067.1 came out).


Maybe there's a newer GDC build that isn't on travis yet? Current 
lastest (using "gdc" in .travis.yml), checked as of 13 hours ago, is 
reporting this:


gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-58ec4c13ec) 4.9.3


There's also a "gdc-5.2.0" that (checked as of this past April, anyway - 
not sure if there would be a newer "gdc-5.2.0" though), reports:


gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-dadb5a3784) 5.2.0




If his lib isn't tested to support up-to-date D compilers (especially the
import changes in 2.070, but there's other stuff as well), that's going to
prevent a lot of people from being able to use his lib. So much for
availability to the masses.



The fixes to import behaviour only breaks forwards compatibility, not
backwards compatibility.



Not sure what your point is here. If you're writing a library and want 
to avoid giving your users deprecation messages due to the import 
changes, then you need to test on 2.070 or newer. Clean compilation on 
pre-2.070 does not guarantee clean compilation on 2.070+.



The problem with compatibility is a library problem, not a compiler IMO.



Since compiler versions and druntime/phobos versions are still pretty 
much a packaged deal, the distinction is irrelevent.

Re: Render SVG To Display And Update Periodically

[ketmar via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 03:27:10 UTC, Basile B. wrote:
https://github.com/Pctg-x8/nanovg-d, I even think it's been 
announced here last year.


this is wrapper. my thing is complete port.

Re: Render SVG To Display And Update Periodically

[ketmar via Digitalmars-d-learn]

On Tuesday, 18 October 2016 at 21:00:12 UTC, Karabuta wrote:

This thing really needs a GitHub repo

never.

Re: Render SVG To Display And Update Periodically

[Jason C. Wells via Digitalmars-d-learn]

This is probably a general programming question. I'll follow up 
here since this thread is the inspiration for my current question.


When attempting to compile simpledisplay.d, I get the following:

C:\...\dlang\arsd-master>dmd -Lgdi32.lib -L user32.lib 
simpledisplay.d color.d

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Warning 9: Unknown Option : NOIGDI32.LIBUSER32.LIB
simpledisplay.obj(simpledisplay)
 Error 42: Symbol Undefined _D9invariant12_d_invariantFC6ObjectZv
simpledisplay.obj(simpledisplay)
** snip **

Interestingly enough, simpledisplay.obj and simpledisplay.exe are 
produced. Aren't errors fatal? The EXE is not a valid win32 
application.


I am used to makefiles. The author doesn't use dub for these 
programs. (dub ~=make?)


gdi32.lib and user32.lib appear in multiple directories.  I added 
"C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64" to 
%LIB% which seemed sensible to do. I still get the warning:


OPTLINK : Warning 9: Unknown Option : NOIGDI32.LIBUSER32.LIB

So, I'm still figuring out how to set up a compile. I presume 
that dmd is not finding gdi32.lib and user32.lib.  What am I 
missing?


Regards,
Jason C. Wells

Re: I close BIP27. I won't be pursuing BIPs anymore

[Shachar Shemesh via Digitalmars-d]

On 18/10/16 07:34, Walter Bright wrote:

You've gotten user defined attributes in the language (and very
undemocratically, I might add!), Win64 support, VC++ symbolic debug
info, a number of improvements to C++ class support, SIMD support, SIMD
intrinsics, pragma inline, yeah, we never listen to you :-)

You've been a large influence over D, and a very positive one.


I take issue with that statement. Not with Manu being a positive 
influence, of course, but with the legitimacy of telling someone what it 
is they should care about. Andrei is known to have done it as well (with 
statements such as "choose your battles and fight them well").


You cannot tell someone volunteering his time to not care about some 
thing. This is simply not how you create a heterogeneous community.


This is also a very bad strategy. If you accept the premise that it is 
possible for something to be flawed, but for both you and Andrei to not 
understand it is so (i.e. - the premise that both you and Andrei are 
human with human failing), any system in which you can control what gets 
discussed is a system that guarantees that this flaw will never get fixed.


I understand that certain topics seem to crop up again and again, and 
the discussions around them seem circular. There are ways to prevent 
that without shutting down people.


For example, taking a page from one of my pet peeves, if anyone bringing 
up integer promotion is not dealt with "yeah, we've discussed that and 
it's pointless to bring it up", but instead is shown the counter 
examples that halted the discussion the previous time, I believe several 
things will happen:


1. People will feel they are listened to. The decision will seem (but, I 
believe, also actually be) less arbitrary.
2. People will know where to focus their attention if they wish for this 
to change

3. Someone may actually find a solution.

You cannot argue with "this will never happen". You can argue with "this 
doesn't work because of X".


Shachar

Re: Static Length Propagation of Ranges

[Meta via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 20:15:14 UTC, Nordlöw wrote:

On Wednesday, 19 October 2016 at 20:13:15 UTC, Nordlöw wrote:

On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:

Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234


I would add this: not sure if it's what you're intending or 
not, but as `in` expands to `const scope` and the semantics 
of scope will probably be changing soon (or more accurately, 
actually implemented), you may want to just go with `const` 
instead.


Ok, thanks. I updated.


BTW: So what about const ref? Will this differ to `in` with 
regards to `scope`? If so will the compiler(s) be smart enough 
to not copy the large stack array when I only qualify with 
`const`?


Well, scope does not imply ref so in both cases a copy will be 
made.

Re: Checkedint ready for one more round of reviews

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/16 6:19 PM, Lurker wrote:

On Wednesday, 19 October 2016 at 17:09:35 UTC, Andrei Alexandrescu wrote:

Just made one more pass through it addressing concerns and adding a
new policy (Throw). Reviews welcome. Let's get this through Scylla and
Charybdis!



This module provides a few predefined hooks (below) that add useful
behavior to Checked:


Missing Throw.


ThrowForce all integral errors to fail by printing an error
message to stderr and then abort the program. Abort is the default
second argument for Checked.


Seems to be copy-pasted from Abort.


Eh, it was indeed :o). Looking back I still see a few places in the 
documentation that I neglected. Will fix. The behavior is there. -- Andrei

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/16 9:04 PM, Walter Bright wrote:

The only way to move this forward is to write a DIP.


I'd be willing to shepherd a DIP if a couple of people want to get 
serious about it. -- Andrei

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Manu via Digitalmars-d]

On 20 October 2016 at 11:04, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote:
>
>> Right, I was arguing this for years. Using 'scope' to make the concept
>> @safe.
>> It seemed that it in the past the key reason for rejecting it was because
>> it was
>> unsafe to pass an rvalue-temp to a function where it's unknown if the
>> function
>> can cause it to outlive the function call... scope was the obvious
>> resolution to
>> that (along with a lot of other issues related to safety).
>>
>
> C++ has had two goes at rvalue references. Any serious proposal for that
> for D needs to include an analysis of what went right/wrong with the C++
> one, and how the D one gets it right.
>

We're not talking about rvalue references...? I'm not sure where this
conversation got confused.

The only way to move this forward is to write a DIP. Having the various
> bits of information spread out over various posts for months (years?) is
> never going to work.
>

Like, 6 or 7 years ;) .. But I think we're talking about different things
at this point.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 20, 2016 10:23:35 Manu via Digitalmars-d wrote:
> On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d <
>
> digitalmars-d@puremagic.com> wrote:
> > On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via
> > Digitalmars-d
> >
> > wrote:
> > > This was C++'s big un' that led to many complications. If the overload
> > > weren't ambiguous, a large part of rvalue references would have been
> > > unneeded. (Universal references would still have been necessary for
> > > perfect forwarding, but that's not the bulk.)
> > >
> > > In order to avoid such issues, we steered clear off binding rvalues to
> > > ref parameters in the D language. As I mentioned to Ethan, I do agree a
> > > careful definition may be able to avoid the fallout that happened in
> > > C++. It would be a fair amount of work.
> >
> > The other big problem is that D's const is so much more restrictive than
> > C++'s that even if const ref accepted rvalues, a large portion of the
> > time,
> > it would be too restrictive to be useful.
>
> I've never seen a piece of code in C++ that receives const& that isn't
> strictly read-only.
> I can't imagine from experience how D's const would change the usefulness
> of the pattern.

The transitivity of const shoot stuff in the foot pretty thoroughly in a
number of cases. A prime example would be ranges, because they have to be
mutated to be iterated over. If the function actually took a range directly,
you wouldn't bother with const ref, but it could be an object that contains
a range, and because you can't normally get a tail-const range from a const
range (aside from dynamic arrays), it can become quite difficult to actually
iterate over the range. e.g.

auto foo(ref const(Bar) bar)
{
auto range = bar.getSomeRange();
...
}

Because getSomeRange would have to be const (or inout) in order to be
called, the return type is going to have be const if there are any
indirections in it. And if it's const, and it's a range, it's useless.

If this were C++, const wouldn't be transitive, so it would be trivial to
get an iterator or range which wasn't const and did not violate const or
attempt to work around it in any way and thus could be iterated. But in D,
const is far too restrictive for that to work.

This is the kind of problem that quickly makes you start wondering whether
it's even worth trying to use const in D at all.

- Jonathan M Davis

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Walter Bright via Digitalmars-d]

On 10/19/2016 5:26 PM, Manu via Digitalmars-d wrote:

Right, I was arguing this for years. Using 'scope' to make the concept @safe.
It seemed that it in the past the key reason for rejecting it was because it was
unsafe to pass an rvalue-temp to a function where it's unknown if the function
can cause it to outlive the function call... scope was the obvious resolution to
that (along with a lot of other issues related to safety).


C++ has had two goes at rvalue references. Any serious proposal for that for D 
needs to include an analysis of what went right/wrong with the C++ one, and how 
the D one gets it right.


The only way to move this forward is to write a DIP. Having the various bits of 
information spread out over various posts for months (years?) is never going to 
work.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Manu via Digitalmars-d]

On 20 October 2016 at 04:18, Namespace via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis wrote:
>
>> Which then causes the problem that it becomes much less clear whether ref
>> is supposed to be modifying its argument or is just trying to avoid copying
>> it - though good documentation can mitigate that problem.
>>
>> - Jonathan M Davis
>>
>
> As long as it would be marked with scope (or some similar attribute) so
> that it cannot escape, it would be fine, wouldn't it?
>

Right, I was arguing this for years. Using 'scope' to make the concept
@safe.
It seemed that it in the past the key reason for rejecting it was because
it was unsafe to pass an rvalue-temp to a function where it's unknown if
the function can cause it to outlive the function call... scope was the
obvious resolution to that (along with a lot of other issues related to
safety).

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Manu via Digitalmars-d]

On 20 October 2016 at 01:38, Jonathan M Davis via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via
> Digitalmars-d
> wrote:
> > This was C++'s big un' that led to many complications. If the overload
> > weren't ambiguous, a large part of rvalue references would have been
> > unneeded. (Universal references would still have been necessary for
> > perfect forwarding, but that's not the bulk.)
> >
> > In order to avoid such issues, we steered clear off binding rvalues to
> > ref parameters in the D language. As I mentioned to Ethan, I do agree a
> > careful definition may be able to avoid the fallout that happened in
> > C++. It would be a fair amount of work.
>
> The other big problem is that D's const is so much more restrictive than
> C++'s that even if const ref accepted rvalues, a large portion of the time,
> it would be too restrictive to be useful.
>

I've never seen a piece of code in C++ that receives const& that isn't
strictly read-only.
I can't imagine from experience how D's const would change the usefulness
of the pattern.

[Issue 16607] [REG2.072b1] "forward reference" error with structs nested in struct templates

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
Also caused by the 2nd commit of that PR
https://github.com/dlang/dmd/pull/5500/commits/75b5b691555bef2d2f21b44821f297f93ddfbc77.

--

[Issue 16627] [Reg 2.072] struct with disabled postblit field is now nested

[via Digitalmars-d-bugs]

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

--- Comment #1 from Martin Nowak  ---
Caused by the 2nd commit of that PR
https://github.com/dlang/dmd/pull/5500/commits/75b5b691555bef2d2f21b44821f297f93ddfbc77.

--

[Issue 16613] integrate dub project tester with dlang's CI

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
Preview ci.dawg.eu, still missing proper github integration.

--

[Issue 16572] [Reg 2.072.0-b1] can't take inout delegate

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/847baa9210e62dbb058b86031a2b36e3a1195440
fix Issue 16572 - can't take inout delegate

https://github.com/dlang/dmd/commit/dea09f5e54065b6bb0cf65fcf78b0e91b7974d23
Merge pull request #6195 from MartinNowak/fix16572

--

[Issue 16563] [REG 2.072.0-b1] Wrong struct size/alignment in local struct

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/07bbf2d0ef547339dee5e886a1a924691c3eb8b8
fix Issue 16563 - wrong alignment in function

https://github.com/dlang/dmd/commit/bf1c25d74964ab3d32d91ecd37f00b99919e5bee
Merge pull request #6196 from MartinNowak/fix16563

--

[Issue 16627] New: [Reg 2.072] struct with disabled postblit field is now nested

[via Digitalmars-d-bugs]

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

  Issue ID: 16627
   Summary: [Reg 2.072] struct with disabled postblit field is now
nested
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
void bug(A...)(ref A args)
{
struct S { A expand; } // no references
static assert(!__traits(isNested, S)); // suddenly nested
}

struct SNoCopy
{
@disable this(this);
}

void test()
{
SNoCopy itm;
bug(itm);
}
CODE
dmd -c bug


Apparently caused by https://github.com/dlang/dmd/pull/5500.

--

[Issue 16626] [Reg 2.073] recent dmd nightly runs out of memory building Higgs

[via Digitalmars-d-bugs]

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

--- Comment #1 from Martin Nowak  ---
Seems to happen for 2 ctRegex to filter out non-alphanumerical characters.

auto nonAlnum = ctRegex!(`[^\w]`w);
enum notAlnum = ctRegex!(`[^0-9|a-z|A-Z]`, "g");

--

Re: Binding rvalues to const ref in D

[Chris Wright via Digitalmars-d]

On Wed, 19 Oct 2016 21:19:03 +, Atila Neves wrote:

> On Wednesday, 19 October 2016 at 15:58:23 UTC, Chris Wright wrote:
>> On Wed, 19 Oct 2016 15:18:36 +, Atila Neves wrote:
>>
>>> The situation is this: if one wants move semantics, one must know when
>>> one can move. Because rvalues bind to const& in C++,
>>> you never know whether the const& is an lvalue or rvalue.
>>
>> To clarify:
>>
>> You copy lvalues instead of moving them. You move rvalues instead of
>> copying them. This has an impact when you assign or pass a ref struct
>> variable to a non-ref variable.
> 
> Then there's this:
> 
> void foo(ref Foo); //doesn't copy lvalues void foo(Foo);
> 
> What's a ref struct variable?

A variable whose type is a struct and which has the `ref` modifier.

>> As a practical matter, whenever I come up against a case where I need
>> to pass something by reference but it's an rvalue, I assign a temporary
>> variable (after scratching my head at an inscrutable message because,
>> hey, everyone's using templates right now and the error message just
>> tells me that I can't pass a DateTime to something expecting a ref T).
> 
> I'm assuming this happens because you don't control the signature of the
> function you're calling and it takes by ref?

Right. For instance, binding query parameters with mysql-native. The 
thing you're binding is passed by reference and I'm not sure why.

[Issue 16626] New: [Reg 2.073] recent dmd nightly runs out of memory building Higgs

[via Digitalmars-d-bugs]

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

  Issue ID: 16626
   Summary: [Reg 2.073] recent dmd nightly runs out of memory
building Higgs
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

Building a debug tests of Higgs[¹] doesn't finish building and runs out of
memory with dmd-2016-10-10 (v2.073.0-master-9a935f6). Only takes about 2GB with
dmd-2016-10-09 (v2.073.0-master-321c95e).
According to verbose output it hangs at `semantic3 parser`.

Digger says it's caused by https://github.com/dlang/phobos/pull/4286.

[¹]: https://github.com/higgsjs/Higgs

--

Re: gdc in Linux distros recommended?

[David Nadlinger via Digitalmars-d]

On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
I'd say start with DMD, as it comes practically free of 
dependencies […]


The same applies to LDC. If you want, you can use the 
self-contained binary releases, which just require the system 
linker to be present, like DMD does.


 — David

Re: Checkedint ready for one more round of reviews

[Lurker via Digitalmars-d]

On Wednesday, 19 October 2016 at 17:09:35 UTC, Andrei 
Alexandrescu wrote:
Just made one more pass through it addressing concerns and 
adding a new policy (Throw). Reviews welcome. Let's get this 
through Scylla and Charybdis!


This module provides a few predefined hooks (below) that add 
useful behavior to Checked:


Missing Throw.

Throw	Force all integral errors to fail by printing an error 
message to stderr and then abort the program. Abort is the 
default second argument for Checked.


Seems to be copy-pasted from Abort.

Silicon Valley D Meetup - October 27, 2016 - "D runtime infrastructure for your projects" by Ilya Yaroshenko

[Ali Çehreli via Digitalmars-d-announce]

We're excited to have Ilya as our guest speaker this month!

From Ilya: I will talk about the future D runtime infrastructure which 
is required for D ecosystem to be desirable for business in large scale. 
A concept I would like to discuss can be called better C.Tags: Mir, 
libmir/cpuid, nothrow @nogc, LDC, LLVM, GPU, Julia, Eigen, C++, 
workforce, async I/O, generic building blocks, HTTP2.


Read more about Ilya's work on Mir:


http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html

Logistics: We'll have some food and drink starting at 7.  Ilya will join 
us at 7:30 by Google Hangouts.


  http://www.meetup.com/D-Lang-Silicon-Valley/events/234353529/

We will post Google Hangouts link here when we create it at the time of 
the meetup.


Ali

Re: gdc in Linux distros recommended?

[Iain Buclaw via Digitalmars-d]

On 19 October 2016 at 21:25, TheGag96 via Digitalmars-d
 wrote:
> On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
>>
>> On the other hand LDC subjectively offers a couple more D specific
>> enhancements, like turning GC allocations into stack allocations in trivial
>> cases
>
>
> Whoa, seriously? I know it's a bit off-topic, but do you have a code example
> of where this would happen? That's amazing!
>

Not to be the one to downplay something.  But it's actually pretty boring. ;-)

An example in GDC would be where a closure was created, but the
nesting function was inlined or optimized away.

In the latter case, you may see something like the following in the DCE pass.

int foo()
{
  closure = _d_allocmemory (8);
  closure.bar = 0;

  return 0;
}

Using a mixture of having a closure that is set but never read, and
giving the optimizer the right hints about what "allocmemory" does
means that it removes the call as dead code.

The exact same is done in the former case, you just convert the
closure to a stack frame, removing the dead call the allocmemory.

Re: Binding rvalues to const ref in D

[Atila Neves via Digitalmars-d]

On Wednesday, 19 October 2016 at 15:58:23 UTC, Chris Wright wrote:

On Wed, 19 Oct 2016 15:18:36 +, Atila Neves wrote:

The situation is this: if one wants move semantics, one must 
know when one can move. Because rvalues bind to const& in C++, 
you never know whether the const& is an lvalue or rvalue.


To clarify:

You copy lvalues instead of moving them. You move rvalues 
instead of copying them. This has an impact when you assign or 
pass a ref struct variable to a non-ref variable.


Then there's this:

void foo(ref Foo); //doesn't copy lvalues
void foo(Foo);

What's a ref struct variable?

As a practical matter, whenever I come up against a case where 
I need to pass something by reference but it's an rvalue, I 
assign a temporary variable (after scratching my head at an 
inscrutable message because, hey, everyone's using templates 
right now and the error message just tells me that I can't pass 
a DateTime to something expecting a ref T).


I'm assuming this happens because you don't control the signature 
of the function you're calling and it takes by ref?


So it seems like the compiler could take care of this by only 
providing lvalue references but automatically creating those 
temporary variables for me. It's going to create an extra copy 
that might not be needed if there were a special rvalue 
reference type modifier, but why should I care? It's exactly as 
efficient as the code the compiler forces me to write.


This is what Ethan Watson has suggested, too.


Interesting. Also, I must have missed that suggestion.


Atila

Re: gdc in Linux distros recommended?

[Iain Buclaw via Digitalmars-d]

On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d
 wrote:
> On 10/18/2016 07:02 PM, Ali Çehreli wrote:
>>
>> I have a friend who has started writing a library in D.
>>
>> Although I recommended that he should use a recent dmd or ldc, he thinks
>> gdc is a better candidate because it's "available to the masses" through
>> Linux distros similar to how gcc is. Although he has a good point, the
>> gdc that came with his distro does not even support @nogc.
>>
>> Thoughts? Can you please tell him to change his mind! :p
>>
>> Ali
>
>
> The last GDC release is stuck all the way back at DMDFE v2.066, which is
> over two years old. Very few libs/projects are going to still be supporting
> that, there's just too much limitation going back that far. LDC had been
> keeping up much better.
>

The core devs are becoming much more receptive to the idea of a
release that has fixes maintained for longer periods of time.  While I
welcome this, it may have come too little, too late.

And GDC is using the 2.068 feature set, plus a lot of bug fixes from
later versions.  I guess you could call it 2.068.5.  :-)

> Due to incompatibilities and necessary features/bugfixes, pretty much all of
> my projects have already been forced to drop support for DMDFE v2.066, and
> GDC in the process. And I *prefer* to maintain compatibility as far back as
> I can.
>
> If his lib isn't tested to support up-to-date D compilers (especially the
> import changes in 2.070, but there's other stuff as well), that's going to
> prevent a lot of people from being able to use his lib. So much for
> availability to the masses.
>

The fixes to import behaviour only breaks forwards compatibility, not
backwards compatibility.

The problem with compatibility is a library problem, not a compiler IMO.

[Issue 15830] UFCS prevents to select a free function when the parameter has a member with the same name

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||blouti...@gmail.com

--- Comment #2 from b2.t...@gmx.com ---
*** Issue 11836 has been marked as a duplicate of this issue. ***

--

[Issue 11836] UFCS doesn't overload methods

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from b2.t...@gmx.com ---


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

--

Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust

[Dennis Ritchie via Digitalmars-d-announce]

On Wednesday, 19 October 2016 at 17:05:18 UTC, Gary Willoughby 
wrote:
D was doing well but in the larger examples the D compiler 
crashed: "Error: more than 32767 symbols in object file".


A bug of this series:
https://issues.dlang.org/show_bug.cgi?id=14315

Re: Why are homepage examples too complicated?

[Karabuta via Digitalmars-d]

On Wednesday, 19 October 2016 at 09:28:28 UTC, Benjiro wrote:

On Tuesday, 18 October 2016 at 20:51:24 UTC, Karabuta wrote:

[...]


True. Anybody can make a website. A website that is efficient, 
takes time. A stupid travel booking website took over a year 
with constant meeting to design around here. The result is a 
efficient design but it takes time.


[...]


On Wednesday, 19 October 2016 at 09:28:28 UTC, Benjiro wrote:

I like this guy :) (You are the first person I ever liked here)

Re: Binding rvalues to const ref in D

[Ali Çehreli via Digitalmars-d]

On 10/19/2016 08:18 AM, Atila Neves wrote:

> Did you know there's more
> than one kind of rvalue in C++? Oh yes:
>
> http://en.cppreference.com/w/cpp/language/value_category
>
> Do we want that?

NO!

My off-topic contribution to this thread: I won't be surprised when C++ 
will eventually be classified as a case of mass hysteria.


Ali

Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust

[Nordlöw via Digitalmars-d-announce]

On Wednesday, 19 October 2016 at 17:05:18 UTC, Gary Willoughby 
wrote:

crashed: "Error: more than 32767 symbols in object file".


Will that many symbols ever happen in real applications?

Anyway, nice!

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Namespace via Digitalmars-d]

On Wednesday, 19 October 2016 at 19:19:35 UTC, Jonathan M Davis 
wrote:
That's an orthogonal issue. My point is that normally, a 
parameter is a ref parameter, because the function is going to 
use that value and potentially mutate it in the process, and 
you want the original variable that was passed in to be mutated 
rather than for the function to be operating on a copy. 
However, once you can pass rvalues to ref parameters, there 
will likely be a sharp increase in the number of ref parameters 
whose entire purpose in being ref is to avoid a copy rather 
than because the original variable is supposed to be mutated. 
That increases the risk of accidentally mutating function 
arguments as well as making it far less obvious when a function 
is supposed to be mutating its argument. C++ solved that 
problem by making it so that only const ref parameters could 
take rvalues, whereas we would be totally open to it if 
non-const ref parameters accepted rvalues.


Whether the argument escapes the function doesn't matter for 
any of that. There may be good reasons why you don't want it 
to, in which case, if scope is implemented to prevent ref 
parameters from escaping, scope will give you that. But just 
because you want to mutate the ref argument doesn't necessarily 
mean that you care about it escaping. You _do_ care if the 
purpose is simply to avoid a copy, because you don't want the 
rvalue to escape, since that would be an @safety issue, and so 
it would make sense to require scope in that case, but at best, 
that means that the lack of scope indicates that the ref 
argument is supposed to be mutated as opposed to simply avoid a 
copy, whereas scope ref says nothing about whether the ref 
argument is supposed to be mutated or simply avoid a copy - 
just that whatever the argument is, it should no escape.


Ok, I understand what you mean, but as long as the argument 
cannot escape I have a different opinion.


So, arguably, it makes more sense to have a new attribute that 
makes it specifically so that a ref accepts rvalues (e.g. 
@rvalue ref) rather than making ref in general accept rvalues 
(the new attribute could even imply scope, since it would be 
required), but that would mean adding yet another attribute, 
and we arguably have too many of those already.


- Jonathan M Davis


Yes, we have way to many. So it would make more sense if we add 
helper/wrappers into phobos (at least for the time being) and 
refer to them.
My byRef "hack" or even my last experiment below could lower the 
dissatisfaction.



struct Vector2f
{
float x, y;
}

void one(ref const Vector2f v)
{
writeln(v.x, '|', v.y);
}

void two(ref const Vector2f source, ref const Vector2f target)
{
writefln("From (%.2f|%.2f) to (%.2f|%.2f)", source.x, 
source.y, target.x, target.y);

}

void invoke(alias f, V...)(V vs)
{
f(vs);
}

void invoke(F, V...)(F f, V vs)
{
f(vs);
}

invoke!one(Vector2f(10, 20));
invoke!two(Vector2f(1, 2), Vector2f(3, 4));

invoke(, Vector2f(10, 20));
invoke(, Vector2f(1, 2), Vector2f(3, 4));

Re: Static Length Propagation of Ranges

[Nordlöw via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 20:13:15 UTC, Nordlöw wrote:

On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:

Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234


I would add this: not sure if it's what you're intending or 
not, but as `in` expands to `const scope` and the semantics of 
scope will probably be changing soon (or more accurately, 
actually implemented), you may want to just go with `const` 
instead.


Ok, thanks. I updated.


BTW: So what about const ref? Will this differ to `in` with 
regards to `scope`? If so will the compiler(s) be smart enough to 
not copy the large stack array when I only qualify with `const`?

Re: Static Length Propagation of Ranges

[Nordlöw via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 20:10:04 UTC, Meta wrote:

Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234


I would add this: not sure if it's what you're intending or 
not, but as `in` expands to `const scope` and the semantics of 
scope will probably be changing soon (or more accurately, 
actually implemented), you may want to just go with `const` 
instead.


Ok, thanks. I updated.

Re: List defined version specifications

[Johan Engelen via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 10:25:51 UTC, Lodovico Giaretta 
wrote:

Hi!

A simple question: is there a way to list all defined version 
specifications?


Perhaps not what you are looking for but on the commandline:


 bin/ldc2 -v test.d

...
predefs   LDC all D_Version2 assert X86_64 D_InlineAsm_X86_64 
D_HardFloat
  LittleEndian D_LP64 D_PIC OSX darwin Posix D_ObjectiveC 
LDC_LLVM_309


-Johan

Re: Static Length Propagation of Ranges

[Meta via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 19:39:46 UTC, Nordlöw wrote:

On Wednesday, 19 October 2016 at 19:01:50 UTC, Meta wrote:

https://goo.gl/t9m3YK

I'm actually pretty impressed that this kind of code can be 
written in D.


Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234


I would add this: not sure if it's what you're intending or not, 
but as `in` expands to `const scope` and the semantics of scope 
will probably be changing soon (or more accurately, actually 
implemented), you may want to just go with `const` instead.

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #11 from b2.t...@gmx.com ---
The regression is still there (b2). Now that the alias is back inside the class
a derived must be instantiated in order to trigger the error. So the procedure
to see it is like in the first post:

$ if [ -d kheops ]; then
$ cd kheops
$ git pull
$ cd ..
$ else
$ git clone https://github.com/BBasile/kheops.git
$ fi
$ cd kheops/runnable
$ dub default_alignment.d 

I think that you did not see it because the unittest config does nothing (it's
a static library).

--

Re: Binding rvalues to const ref in D

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 19 October 2016 at 15:18:36 UTC, Atila Neves wrote:
My question is: do you _really_ need rvalues to bind to const 
ref for performance? If not, what _do_ you need it for? Is it 
an instinctive reaction against passing structs by value from 
C++98 days?


imho it's the compiler job to pass by value or ref. For a 
function that is inlined it should be able to make its on choice.

Re: Static Length Propagation of Ranges

[Nordlöw via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 19:01:50 UTC, Meta wrote:

https://goo.gl/t9m3YK

I'm actually pretty impressed that this kind of code can be 
written in D.


Thanks! Add at

https://github.com/nordlow/phobos-next/blob/master/src/algorithm_ex.d#L2234

Re: gdc in Linux distros recommended?

[TheGag96 via Digitalmars-d]

On Wednesday, 19 October 2016 at 03:29:10 UTC, Marco Leise wrote:
On the other hand LDC subjectively offers a couple more D 
specific enhancements, like turning GC allocations into stack 
allocations in trivial cases


Whoa, seriously? I know it's a bit off-topic, but do you have a 
code example of where this would happen? That's amazing!

Re: rvalue references

[Marco Leise via Digitalmars-d]

Am Wed, 19 Oct 2016 11:29:50 +0200
schrieb Timon Gehr :

> Yes, the lack of rvalue references can be annoying but 'const' should be 
> orthogonal to any implemented solution.
> 
> There should be a way to pass rvalues by reference that are not 
> prevented from being mutated, and it should be the same way as for const 
> references. (For example, one possible approach is to just allow rvalues 
> to bind to all 'ref' parameters (as is done for the implicit 'this' 
> reference), alternatively there could be some additional "allow rvalues 
> here" annotation that does not influence mutability.)

Ok, got ya now!

-- 
Marco

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Jonathan M Davis via Digitalmars-d]

On Wednesday, October 19, 2016 18:18:43 Namespace via Digitalmars-d wrote:
> On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis
>
> wrote:
> > Which then causes the problem that it becomes much less clear
> > whether ref is supposed to be modifying its argument or is just
> > trying to avoid copying it - though good documentation can
> > mitigate that problem.
> >
> > - Jonathan M Davis
>
> As long as it would be marked with scope (or some similar
> attribute) so that it cannot escape, it would be fine, wouldn't
> it?

That's an orthogonal issue. My point is that normally, a parameter is a ref
parameter, because the function is going to use that value and potentially
mutate it in the process, and you want the original variable that was passed
in to be mutated rather than for the function to be operating on a copy.
However, once you can pass rvalues to ref parameters, there will likely be a
sharp increase in the number of ref parameters whose entire purpose in being
ref is to avoid a copy rather than because the original variable is supposed
to be mutated. That increases the risk of accidentally mutating function
arguments as well as making it far less obvious when a function is supposed
to be mutating its argument. C++ solved that problem by making it so that
only const ref parameters could take rvalues, whereas we would be totally
open to it if non-const ref parameters accepted rvalues.

Whether the argument escapes the function doesn't matter for any of that.
There may be good reasons why you don't want it to, in which case, if scope
is implemented to prevent ref parameters from escaping, scope will give you
that. But just because you want to mutate the ref argument doesn't
necessarily mean that you care about it escaping. You _do_ care if the
purpose is simply to avoid a copy, because you don't want the rvalue to
escape, since that would be an @safety issue, and so it would make sense to
require scope in that case, but at best, that means that the lack of scope
indicates that the ref argument is supposed to be mutated as opposed to
simply avoid a copy, whereas scope ref says nothing about whether the ref
argument is supposed to be mutated or simply avoid a copy - just that
whatever the argument is, it should no escape.

So, arguably, it makes more sense to have a new attribute that makes it
specifically so that a ref accepts rvalues (e.g. @rvalue ref) rather than
making ref in general accept rvalues (the new attribute could even imply
scope, since it would be required), but that would mean adding yet another
attribute, and we arguably have too many of those already.

- Jonathan M Davis

Re: Static Length Propagation of Ranges

[Meta via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 18:56:35 UTC, Meta wrote:
Couldn't you do this? Mind you I'm not able to test the code 
right now, but I think it can work with some tweaking.


typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] 
container)

{
import std.algorithm.iteration : map;
import std.array : array;

typeof(return) sres;
return container[].map!fn.copy(sres[]);
}

@safe pure nothrow unittest
{
   int[42] c;
   //result should be a static array of length 42
   auto result = map1!(_ => _^2)(c);
}


Sorry, that code had a few mistakes. The working code:

import std.algorithm;
import std.range;

typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] container)
{
import std.algorithm.iteration : map;
import std.array : array;

typeof(return) sres;
container[].map!fn.copy(sres[]);
return sres;
}

void main()
{
   int[42] c;
   //result should be a static array of length 42
   auto result = map1!(_ => _^2)(c);
   assert(is(typeof(result) == typeof(c)));
}

https://goo.gl/t9m3YK

I'm actually pretty impressed that this kind of code can be 
written in D.

Re: Static Length Propagation of Ranges

[Meta via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 13:59:29 UTC, Nordlöw wrote:

Is there a generic way to do


typeof(fn(E.init))[] map1(alias fn, E, size_t n)(E[n] container)
{
  import std.algorithm.iteration : map;
  import std.array : array;
  return container[].map!fn.array;
}

@safe pure nothrow unittest
{
  int[42] c;
  auto result = map1!(_ => _^2)(c);
}


but with propagation of length of return value of `f` to a 
static array instead, without having to specialize each range 
separately?


One less elegant way would be to replace the call to `array` 
with an overload of `std.container.util.make` for static 
arrays, that checks at run-time that the length of the output 
static array matches the length of the input range?


Couldn't you do this? Mind you I'm not able to test the code 
right now, but I think it can work with some tweaking.


typeof(fn(E.init))[n] map1(alias fn, E, size_t n)(E[n] container)
{
import std.algorithm.iteration : map;
import std.array : array;

typeof(return) sres;
return container[].map!fn.copy(sres[]);
}

@safe pure nothrow unittest
{
   int[42] c;
   //result should be a static array of length 42
   auto result = map1!(_ => _^2)(c);
}

Re: I close BIP27. I won't be pursuing BIPs anymore

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 19 October 2016 at 17:54:15 UTC, Namespace wrote:

That's more ore less the magic behind auto ref.


Thanks. Failed to find the related bit in the spec.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Namespace via Digitalmars-d]

On Wednesday, 19 October 2016 at 18:15:25 UTC, Jonathan M Davis 
wrote:
Which then causes the problem that it becomes much less clear 
whether ref is supposed to be modifying its argument or is just 
trying to avoid copying it - though good documentation can 
mitigate that problem.


- Jonathan M Davis


As long as it would be marked with scope (or some similar 
attribute) so that it cannot escape, it would be fine, wouldn't 
it?

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Jonathan M Davis via Digitalmars-d]

On Wednesday, October 19, 2016 12:48:54 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote:
> > On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via
> > Digitalmars-d>
> > wrote:
> >> This was C++'s big un' that led to many complications. If the overload
> >> weren't ambiguous, a large part of rvalue references would have been
> >> unneeded. (Universal references would still have been necessary for
> >> perfect forwarding, but that's not the bulk.)
> >>
> >> In order to avoid such issues, we steered clear off binding rvalues to
> >> ref parameters in the D language. As I mentioned to Ethan, I do agree a
> >> careful definition may be able to avoid the fallout that happened in
> >> C++. It would be a fair amount of work.
> >
> > The other big problem is that D's const is so much more restrictive than
> > C++'s that even if const ref accepted rvalues, a large portion of the
> > time,
> > it would be too restrictive to be useful.
>
> That's why if we allow binding rvalues to references, we'd allow it
> regardless of const. -- Andrei

Which then causes the problem that it becomes much less clear whether ref is
supposed to be modifying its argument or is just trying to avoid copying it
- though good documentation can mitigate that problem.

- Jonathan M Davis

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #10 from Martin Nowak  ---
Just tested
https://github.com/BBasile/kheops/commit/a00f300c4281b2d4aaf95e7fabde48d3dc3816e9.
This commit did build with 2.070.2, 2.071.2, and still builds with 2.072.0-b2.
Also dub test does pass with 2.071.2 and 2.072.0-b2, so this doesn't show any
regression.

If OTOH the recursive alias is declared outside of the class, all versions fail
to compile.

I went back and tested
https://github.com/BBasile/kheops/commit/2f99686d346c291e1cfbe6e1412373d5cc1a385c
which now also passes tests. Have you fixed some upstream library (e.g. iz)?

I think all the override errors were just follow-up errors from a semantic
analysis failure for the class or it's base class (e.g. due to the recursive
alias).

For your next bug report, please properly document all code involved or even
provide a zip file here. Of course, at best you succeed to reduce the test
case.

--

Re: I close BIP27. I won't be pursuing BIPs anymore

[Namespace via Digitalmars-d]

On Wednesday, 19 October 2016 at 17:42:39 UTC, Guillaume Piolat 
wrote:

On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
I just want to be able to pass an rvalue to a function that 
receives a
const ref... that's why I came to this forum in the first 
place like,

7 years ago. 7 years later... still can't.


I recently wrote a PR for p0nce D idioms, which shows how you 
can do that

https://github.com/p0nce/d-idioms/pull/119


Just wanted to add that I still don't know (I'm lazy) what 
"auto ref" parameters, "auto ref" return, and friends do in D.

ref is somewhat easy to explain in C++ but complicated in D.


For each auto ref argument the compiler will lazily generate 2^N 
functions (therefore "template bloat" if you overdo it). Example:



struct A { int id; }
void test(T)(auto ref T a) { }

A a = A(42);
test(a);


will generate one function, which takes the argument by ref:

void test(ref A a) { }


Another call

test(A(42));


will generate another function, which takes the argument by value:

void test(A a) { }


That's more ore less the magic behind auto ref.

Re: I close BIP27. I won't be pursuing BIPs anymore

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 18 October 2016 at 06:30:15 UTC, Namespace wrote:

On Tuesday, 18 October 2016 at 02:54:08 UTC, Manu wrote:
I just want to be able to pass an rvalue to a function that 
receives a
const ref... that's why I came to this forum in the first 
place like,

7 years ago. 7 years later... still can't.


I recently wrote a PR for p0nce D idioms, which shows how you 
can do that

https://github.com/p0nce/d-idioms/pull/119


Just wanted to add that I still don't know (I'm lazy) what "auto 
ref" parameters, "auto ref" return, and friends do in D.

ref is somewhat easy to explain in C++ but complicated in D.

[Issue 16622] multiple scope(exit) are damaging the stack

[via Digitalmars-d-bugs]

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

--- Comment #2 from robert...@googlemail.com ---
doesn't matter what is thrown if the stack is corrupted :)

void main() {
scope(exit) {}

scope(exit) {throw new Exception("kab00m!");}; return;
}

--

Comparing compilation time of random code in C++, D, Go, Pascal and Rust

[Gary Willoughby via Digitalmars-d-announce]

This was posted on twitter a while ago:

Comparing compilation time of random code in C++, D, Go, Pascal 
and Rust


http://imgur.com/a/jQUav

D was doing well but in the larger examples the D compiler 
crashed: "Error: more than 32767 symbols in object file".

Checkedint ready for one more round of reviews

[Andrei Alexandrescu via Digitalmars-d]

Just made one more pass through it addressing concerns and adding a new 
policy (Throw). Reviews welcome. Let's get this through Scylla and 
Charybdis!


Code: https://github.com/dlang/phobos/pull/4613

Dox: 
http://dtest.thecybershadow.net/artifact/website-c1933a4611fdfd4f996f85d2f37a669f34d58d58-2020d60f92d3b96ef9c94dc8b38c7723/web/library-prerelease/std/experimental/checkedint.html


Docs: 
http://dtest.thecybershadow.net/artifact/website-c1933a4611fdfd4f996f85d2f37a669f34d58d58-2020d60f92d3b96ef9c94dc8b38c7723/web/phobos-prerelease/std_experimental_checkedint.html



Andrei

Re: Munich D October Meetup

[Ilya Yaroshenko via Digitalmars-d-announce]

On Tuesday, 18 October 2016 at 14:09:14 UTC, Seb wrote:

Hi all,

this month the Munich D Meetup [1] will cover the recent buzz 
about the "Numerical age in D". For example in matrix-matrix 
multiplication Mir GLAS beat the OpenBLAS and Eigen math 
libraries [2].


We will meet next Wednesday (26.10). Please see the Meetup 
event page [3] for more details.

Everyone is cordially invited.

See you there,

[1] Munich D Meetup Group:
https://www.meetup.com/de-DE/Munich-D-Programmers/

[2] Numerical age for D
http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html

[3] October Meetup:
https://www.meetup.com/Munich-D-Programmers/events/234940707/


Does it available via Google Hangouts?

Re: Battle-plan for CTFE

[Rory McGuire via Digitalmars-d-announce]

On 19 Oct 2016 17:46, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
>>
>> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
>>>
>>> If all goes well there will be a separate nightly release build from
the newCTFE branch,  sometime in October.
>>>
>>> I hope to get alpha bug reports that way.
>>
>>
>> Have you benchmarked CTFE-heavy projects like Pegged?
>
>
> It is not yet able to handle pegged.
> And I suspect alot of slowness is caused by templates not by CTFE.

diet-ng is probably a better "complex" benchmark.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/2016 11:38 AM, Jonathan M Davis via Digitalmars-d wrote:

On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d
wrote:

This was C++'s big un' that led to many complications. If the overload
weren't ambiguous, a large part of rvalue references would have been
unneeded. (Universal references would still have been necessary for
perfect forwarding, but that's not the bulk.)

In order to avoid such issues, we steered clear off binding rvalues to
ref parameters in the D language. As I mentioned to Ethan, I do agree a
careful definition may be able to avoid the fallout that happened in
C++. It would be a fair amount of work.


The other big problem is that D's const is so much more restrictive than
C++'s that even if const ref accepted rvalues, a large portion of the time,
it would be too restrictive to be useful.


That's why if we allow binding rvalues to references, we'd allow it 
regardless of const. -- Andrei

Any recent success with SWIG?

[Ryan via Digitalmars-d-learn]

I would like to use a library with a c interface from D (gdal 
actually), but I can't find any bindings. I've looked at htod, 
but I also see that gdal has project maintained SWIG interfaces 
and SWIG claims to work with D (both D1 and D2).


So I installed the latest SWIG, but I haven't been able to get 
the SWIG provided D examples to work. Everything compiles, but 
when I run an example I get an Access Violation, it looks like it 
is trying to use a null pointer somewhere.


Has anyone had success with this? Or maybe has SWIG support for D 
fallen behind?


I'm using windows 10 with MSYS2 as my shell environment to 
support the Autotools build files that came with SWIG, which is 
what they recommend on the website for building the examples.


Thanks,

Re: SQLite

[WebFreak001 via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 16:01:37 UTC, Alfred Newman 
wrote:

Hello,

I am trying to handle a SQLite3 table with D. During my 
researchs, I discovered the lib 
https://dlang.org/phobos/etc_c_sqlite3.html.


However, for any reason, there is no code snippets or sample 
codes available there. So, I am stucked.


etc.c.sqlite3 is just a C wrapper, take a look at C examples for 
sqlite3. The D docs don't usually include documentation for 
simple C wrappers.



If you want a proper D library for sqlite3, try d2sqlite3 from 
dub. IMO it's really easy to use and works really well.


Your example using d2sqlite3:

auto stmt = db.prepare("INSERT INTO COMPANY (ID, NAME, AGE, 
ADDRESS, SALARY) VALUES (:id, :name, :age, :address, :salary)");

stmt.inject(1, "Paul", 32, "California", 2);
stmt.inject(2, "Allen", 25, "Texas", 15000);
stmt.inject(3, "Teddy", 23, "Norway", 2);
stmt.inject(4, "Mark", 25, "Rich-Mond", 65000);

Re: std.paralellism.Task value type problems

[Ryan via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 15:28:25 UTC, Benjamin Thaut 
wrote:
I would like to use std.paralellism.TaskPool to schedule 
various tasks I create. The problem however is that these tasks 
don't have a lifetime which is bound to any function scope I 
have. So I need to create a new task object on the heap and 
push it into a array for bookkeeping. The problem however is 
that std.paralellism.Task is a struct and the only way to 
instanciate it is to use std.paralelism.task which returns it 
as a value. I have no idea at the moment how to allocate a 
instance of std.paralellism.Task on the heap. Any suggestions?


Kind Regards
Benjamin Thaut


Try the link below for the documentation. There are 2 versions of 
task, one returns a struct on the stack, the second returns a 
struct on the GC heap.


https://dlang.org/phobos/std_parallelism.html#.task

Re: Binding rvalues to const ref in D

[Johan Engelen via Digitalmars-d]

On Wednesday, 19 October 2016 at 15:18:36 UTC, Atila Neves wrote:


Yes, it's a stupid example. But ldc2 -O3 gives me this for 
`silly`:


Great example, thanks, please more of that :)
https://github.com/ldc-developers/ldc/issues/1842

cheers,
  Johan

Re: SQLite

[bachmeier via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 16:01:37 UTC, Alfred Newman 
wrote:

Hello,

I am trying to handle a SQLite3 table with D. During my 
researchs, I discovered the lib 
https://dlang.org/phobos/etc_c_sqlite3.html.


[...]


I've never used SQLite from D, but Adam Ruppe has an interface 
with an example here:

https://github.com/adamdruppe/arsd/blob/master/sqlite.d

Berlin D Meetup October 2016

[Ben Palmer via Digitalmars-d-announce]

Hi All,

Sorry for the late notice but the October Berlin D Meetup will be 
happening at 20:00 on this Friday the 21st of October at Berlin 
Co-Op (http://co-up.de/) on the fifth floor.


This month Stefan K is going to give a quick introduction to his 
new llvm-backend followed by some time for hackathon type 
activities.


This time Green Gurus are supporting us with some great food 
which is fantastic!


More details are available on the meetup page here: 
http://www.meetup.com/Berlin-D-Programmers/events/234939874/


Thanks,
Ben.

Re: gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/18/2016 07:02 PM, Ali Çehreli wrote:

I have a friend who has started writing a library in D.

Although I recommended that he should use a recent dmd or ldc, he thinks
gdc is a better candidate because it's "available to the masses" through
Linux distros similar to how gcc is. Although he has a good point, the
gdc that came with his distro does not even support @nogc.

Thoughts? Can you please tell him to change his mind! :p

Ali


The last GDC release is stuck all the way back at DMDFE v2.066, which is 
over two years old. Very few libs/projects are going to still be 
supporting that, there's just too much limitation going back that far. 
LDC had been keeping up much better.


Due to incompatibilities and necessary features/bugfixes, pretty much 
all of my projects have already been forced to drop support for DMDFE 
v2.066, and GDC in the process. And I *prefer* to maintain compatibility 
as far back as I can.


If his lib isn't tested to support up-to-date D compilers (especially 
the import changes in 2.070, but there's other stuff as well), that's 
going to prevent a lot of people from being able to use his lib. So much 
for availability to the masses.


And LDC (and DMD, frankly) is every bit as "available to the masses" as 
GDC. The "available to the masses" just seems based more on general 
perception of "GCC" being a big, major name rather than anything concrete.

SQLite

[Alfred Newman via Digitalmars-d-learn]

Hello,

I am trying to handle a SQLite3 table with D. During my 
researchs, I discovered the lib 
https://dlang.org/phobos/etc_c_sqlite3.html.


However, for any reason, there is no code snippets or sample 
codes available there. So, I am stucked.


I have the following sample structure table:
   sql = "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) "  \
 "VALUES (1, 'Paul', 32, 'California', 2.00 ); " \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY) "  \
 "VALUES (2, 'Allen', 25, 'Texas', 15000.00 ); " \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY)" \
 "VALUES (3, 'Teddy', 23, 'Norway', 2.00 );" \
 "INSERT INTO COMPANY (ID,NAME,AGE,ADDRESS,SALARY)" \
 "VALUES (4, 'Mark', 25, 'Rich-Mond ', 65000.00 );";

Can you pls provide a code snippet or some hints to the following 
job:

- Create a table with the layout above
- Iterate through the records given a basic SELECT WHERE Query

Thanks in advance, AN

Re: Binding rvalues to const ref in D

[Chris Wright via Digitalmars-d]

On Wed, 19 Oct 2016 15:18:36 +, Atila Neves wrote:

> The situation is this: if one wants move semantics, one must know when
> one can move. Because rvalues bind to const& in C++, you never know
> whether the const& is an lvalue or rvalue.

To clarify:

You copy lvalues instead of moving them. You move rvalues instead of 
copying them. This has an impact when you assign or pass a ref struct 
variable to a non-ref variable.

As a practical matter, whenever I come up against a case where I need to 
pass something by reference but it's an rvalue, I assign a temporary 
variable (after scratching my head at an inscrutable message because, 
hey, everyone's using templates right now and the error message just 
tells me that I can't pass a DateTime to something expecting a ref T).

So it seems like the compiler could take care of this by only providing 
lvalue references but automatically creating those temporary variables 
for me. It's going to create an extra copy that might not be needed if 
there were a special rvalue reference type modifier, but why should I 
care? It's exactly as efficient as the code the compiler forces me to 
write.

This is what Ethan Watson has suggested, too.

[Issue 16625] [Reg 2.072] new and previously undeprecated switch case fallthrough error

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/6206

--

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:

On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
If all goes well there will be a separate nightly release 
build from the newCTFE branch,  sometime in October.


I hope to get alpha bug reports that way.


Have you benchmarked CTFE-heavy projects like Pegged?


It is not yet able to handle pegged.
And I suspect alot of slowness is caused by templates not by CTFE.

Re: Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Jonathan M Davis via Digitalmars-d]

On Wednesday, October 19, 2016 07:55:19 Andrei Alexandrescu via Digitalmars-d 
wrote:
> This was C++'s big un' that led to many complications. If the overload
> weren't ambiguous, a large part of rvalue references would have been
> unneeded. (Universal references would still have been necessary for
> perfect forwarding, but that's not the bulk.)
>
> In order to avoid such issues, we steered clear off binding rvalues to
> ref parameters in the D language. As I mentioned to Ethan, I do agree a
> careful definition may be able to avoid the fallout that happened in
> C++. It would be a fair amount of work.

The other big problem is that D's const is so much more restrictive than
C++'s that even if const ref accepted rvalues, a large portion of the time,
it would be too restrictive to be useful.

- Jonathan M Davis

std.paralellism.Task value type problems

[Benjamin Thaut via Digitalmars-d-learn]

I would like to use std.paralellism.TaskPool to schedule various 
tasks I create. The problem however is that these tasks don't 
have a lifetime which is bound to any function scope I have. So I 
need to create a new task object on the heap and push it into a 
array for bookkeeping. The problem however is that 
std.paralellism.Task is a struct and the only way to instanciate 
it is to use std.paralelism.task which returns it as a value. I 
have no idea at the moment how to allocate a instance of 
std.paralellism.Task on the heap. Any suggestions?


Kind Regards
Benjamin Thaut

Binding rvalues to const ref in D

[Atila Neves via Digitalmars-d]

New post since the the last one was already off-topic. Continued 
from:


http://forum.dlang.org/post/nu7mv8$mqu$1...@digitalmars.com

I get the feeling that people are talking past each other. I'm 
going to give my view of the situation and everybody can correct 
me if I'm wrong / throw tomatoes at me.code


On the one hand some people want rvalues to bind to const ref. I 
can only assume that they want this because they want to pass 
rvalues to a function efficiently - i.e. put a pointer in a 
register. It might also be due to familiarity with C++ but I 
speculate. If indeed I'm right, then I wonder if it's by instinct 
or if it's been measured versus passing a struct by value. I just 
wrote this:


struct Vector { float x, y, z; }
float silly(Vector v) { return v.x * 5; }

float test() {
Vector v;
return silly(Vector(1, 2, 3)) * 7;
}

Yes, it's a stupid example. But ldc2 -O3 gives me this for 
`silly`:


movq   rax,xmm0
movd   xmm0,eax
mulss  xmm0,DWORD PTR [rip+0x0]
ret

It's a bit longer than if I passed in a float directly:

mulss  xmm0,DWORD PTR [rip+0x0]
ret

But... there's no copying or moving of the entire struct. C++ 
(also passing by value, I just hand-tranlated the code) is 
similar but for some reason was better at optimising:


mulss  xmm0,DWORD PTR [rip+0x0]
ret
nop

Again, no copying or moving. Which is what I expected. Granted, 
real-life code might be complicated enough to make matters a lot 
worse. I'm just wondering out loud how likely that is to happen 
and how big of an impact on total performance that'll have. My 
question is: do you _really_ need rvalues to bind to const ref 
for performance? If not, what _do_ you need it for? Is it an 
instinctive reaction against passing structs by value from C++98 
days?


It's been mentioned that one might not get a say on how a 
function is declared if calling, say, C++ from D. That's a fair 
argument, and one I've not heard a solution for yet. Maybe allow 
rvalues to bind to const ref in `extern(C++)`? I don't know, I'm 
thinking out "loud".



On the other hand we have the "rvalues binding to const ref => 
rvalue references or other complicated mechanisms for figuring 
out whether or not the const ref is an rvalue". This seems to 
have not been explained correctly. I'm not blaming anyone, I just 
tried yesterday and failed as well.


The situation is this: if one wants move semantics, one must know 
when one can move. Because rvalues bind to const& in C++, you 
never know whether the const& is an lvalue or rvalue. The 
solution to this was rvalue references, which are refs that can 
_only_ bind to rvalues. That way you know that the origin was an 
rvalue an wahey, move semantics. They complicated the language 
significantly. Did you know there's more than one kind of rvalue 
in C++? Oh yes:


http://en.cppreference.com/w/cpp/language/value_category

Do we want that? I don't.

Summary:

* rvalues don't bind to const ref because if they did there'd be 
ambiguity, and to solving that problem would make the language 
more complicated.
* Knowing when passed-in parameters were actually rvalues turns 
out to be something compilers want to do because performance.
* It'd be nice if D could call C++ functions that take const& 
with rvalues


Tomato time?

Atila

[Issue 15881] approxEqual Ignores maxAbsDiff

[via Digitalmars-d-bugs]

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

--- Comment #3 from John Hall  ---
If I were designing it from the start, I probably would have used a function
like 
bool approxEqual(T, U, V)(T lhs, U rhs, V maxDiff, bool isAbsolute = FALSE); 

This way you can easily switch from one to the other. It wouldn't break any
code to add this as an additional option. 

The other one could be fixed so as to match the documentation. This would mean
that there is the simple one that's an OR and another version that can handle
the AND case (which some people still might need).

--

Re: Request: Hardened system tutorial/patch

[Lodovico Giaretta via Digitalmars-d]

On Wednesday, 19 October 2016 at 13:16:08 UTC, Daniel Kozak wrote:

[...]


Thank you. I didn't know about dmd.conf.
Do you happen to know which options should I use to disable PIE 
generation? -L-no-pie does not work, so I'm stuck with producing 
PIE executables (which is not bad per se, but as I said I care 
that I can easily switch back and forth when needed).

Static Length Propagation of Ranges

[Nordlöw via Digitalmars-d-learn]

Is there a generic way to do


typeof(fn(E.init))[] map1(alias fn, E, size_t n)(E[n] container)
{
  import std.algorithm.iteration : map;
  import std.array : array;
  return container[].map!fn.array;
}

@safe pure nothrow unittest
{
  int[42] c;
  auto result = map1!(_ => _^2)(c);
}


but with propagation of length of return value of `f` to a static 
array instead, without having to specialize each range separately?


One less elegant way would be to replace the call to `array` with 
an overload of `std.container.util.make` for static arrays, that 
checks at run-time that the length of the output static array 
matches the length of the input range?

Re: Why are homepage examples too complicated?

[Chris via Digitalmars-d]

On Wednesday, 19 October 2016 at 11:30:03 UTC, rikki cattermole 
wrote:

On 20/10/2016 12:08 AM, Andrei Alexandrescu wrote:

On that note, maybe we should setup a 'real code' pool so 
people can see real code, preferably on a few files big that 
does a specific but useful task.


Actually, that'd be great.

Re: Request: Hardened system tutorial/patch

[Daniel Kozak via Digitalmars-d]

Dne 19.10.2016 v 14:51 Lodovico Giaretta via Digitalmars-d napsal(a):


Hi!

As you might have noticed, Ubuntu 16.10 joins the community of 
hardened systems by shipping GCC 6.2 with PIE enabled by default. This 
is a wonderful security choice, but it comes with some problems when 
one tries to use DMD. Here is what happened to me.


1) Trying to unittest std.experimental.xml:

   I got tons of failed relocations, but I was kind of expecting that. 
I was using DUB,
   so I added `"lflags": ["-no-pie"]`, but it didn't do anything and I 
really don't know
   why. Then I tried setting "dflags" with "-fPIC", but it didn't 
suffice, as I had to

   set "-defaultlib" to "libphobos2.so".
   Ok, this finally worked, but it produced PIE executables. What if I 
want to use a plain
   old fixed-position executable? I didn't manage to do that. Also, 
the "default" dmd
   call, without any option, should really work out of the box. I 
don't really care if by
   default it produces PIE or not. I care that I don't have to think 
about it unless it's
   an important decision for me. And I care that if I want, I can 
switch to whatever with

   a command line option.
This is possible, it is on package maintainers to do this (compile 
druntime and phobos itself with -fPIC and add -fPIC to /etc/dmd.conf)




2) Trying to use DUB seriously:

   This is a good reason to have a working default configuration. 
While working on the
   xml library, I used `dub -b ddox`. Being the first time on the new 
system, DUB fetched
   ddox and tried to build it. But of course it failed! And that's 
because ddox (as every
   dub package) does not specify "-fPIC -defaultlib=libphobos2.so", as 
it has never been
   necessary. I still don't know how to make this work without hacking 
ddox.


So, what we really need is either a good tutorial on how to setup 
everything so that it "just works", or even better the compiler should 
recognize if the linker has hardening enabled by default, and take 
actions to either compile with PIC or call the linker with -no-pie.

same as above just add -fPIC to dmd.conf

Request: Hardened system tutorial/patch

[Lodovico Giaretta via Digitalmars-d]

Hi!

As you might have noticed, Ubuntu 16.10 joins the community of 
hardened systems by shipping GCC 6.2 with PIE enabled by default. 
This is a wonderful security choice, but it comes with some 
problems when one tries to use DMD. Here is what happened to me.


1) Trying to unittest std.experimental.xml:

   I got tons of failed relocations, but I was kind of expecting 
that. I was using DUB,
   so I added `"lflags": ["-no-pie"]`, but it didn't do anything 
and I really don't know
   why. Then I tried setting "dflags" with "-fPIC", but it didn't 
suffice, as I had to

   set "-defaultlib" to "libphobos2.so".
   Ok, this finally worked, but it produced PIE executables. What 
if I want to use a plain
   old fixed-position executable? I didn't manage to do that. 
Also, the "default" dmd
   call, without any option, should really work out of the box. I 
don't really care if by
   default it produces PIE or not. I care that I don't have to 
think about it unless it's
   an important decision for me. And I care that if I want, I can 
switch to whatever with

   a command line option.

2) Trying to use DUB seriously:

   This is a good reason to have a working default configuration. 
While working on the
   xml library, I used `dub -b ddox`. Being the first time on the 
new system, DUB fetched
   ddox and tried to build it. But of course it failed! And 
that's because ddox (as every
   dub package) does not specify "-fPIC 
-defaultlib=libphobos2.so", as it has never been
   necessary. I still don't know how to make this work without 
hacking ddox.


So, what we really need is either a good tutorial on how to setup 
everything so that it "just works", or even better the compiler 
should recognize if the linker has hardening enabled by default, 
and take actions to either compile with PIC or call the linker 
with -no-pie.

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #9 from b2.t...@gmx.com ---
(In reply to Martin Nowak from comment #8)
> Well your code doesn't build with any of the past versions of the compiler,
> b/c of the template PublishedObjectArray!(CustomControl) being recursively
> used in a field of CustomControl.
> Can you provide any version of your software that correctly works w/ a
> previous version, but fails to compile now?

done, the alias must be moved in CustomControl. But it means that the reduction
is also invalid. What's really sure is the PR that introduced the regression,
5690.

--

[Issue 15881] approxEqual Ignores maxAbsDiff

[via Digitalmars-d-bugs]

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #2 from John Colvin  ---
Ok, so I just ran in to this with approxEqual(2531.25, 2531) == true, which was
a latent bug hiding in my code for over a year when I thought everything was
working fine.

I would like to get some more opinions from others on this: either we change it
so both relative *and* absolute must be satisfied, or it should be very clearly
documented to only need to satisfy one of them.

--

[Issue 16574] [REG 2.072.0-b1] Unexplained errors about functions that overridde anything

[via Digitalmars-d-bugs]

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

--- Comment #8 from Martin Nowak  ---
Well your code doesn't build with any of the past versions of the compiler, b/c
of the template PublishedObjectArray!(CustomControl) being recursively used in
a field of CustomControl.
Can you provide any version of your software that correctly works w/ a previous
version, but fails to compile now?

--

[Issue 16625] New: [Reg 2.072] new and previously undeprecated switch case fallthrough error

[via Digitalmars-d-bugs]

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

  Issue ID: 16625
   Summary: [Reg 2.072] new and previously undeprecated switch
case fallthrough error
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
uint test(uint val)
{
switch (val)
{
case 1: val <<= 1;
default:
return val;
}
}
CODE

dmd -c bug

bug.d(6): Error: switch case fallthrough - use 'goto default;' if intended


Apparently this was a warning before but that doesn't warrant skipping the
deprecation phase for new errors.

--

Re: gdc in Linux distros recommended?

[ketmar via Digitalmars-d]

On Wednesday, 19 October 2016 at 10:21:43 UTC, Dejan Lekic wrote:

because GDC is not yet merged into GCC.


there is absolutely no reason to do this. while today the 
question of syncing gdc frontend with dmd is only a question of 
manpower, with such a merge gdc will *always* be behind, stucked 
with old versions. and for D this is critical, as each new D 
version brings something better, fix some bugs and so on. it's 
not like C, for example, for which you don't have new 
language/stdlib release each several monthes.


tl;dr: if gdc will be merged to gcc, it will be bad for D, and 
unrecoverable death for gdc.

Binding rvalues to ref [WAS: I close BIP27. I won't be pursuing BIPs anymore]

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/16 1:47 AM, Manu via Digitalmars-d wrote:

On 19 October 2016 at 06:22, Andrei Alexandrescu via Digitalmars-d
> wrote:

On 10/18/2016 04:15 PM, Atila Neves wrote:


I think I get it; I'm just not sure given the comments that pop
up in
the forum. Isn't one of the main reasons distinguishing between
these two?

void fun(ref const Foo);
void fun(Foo);

If they can't be distinguished, you don't get move semantics
"for free".


That's right, thanks Atila. -- Andreu


This is obvious though, lval calls the first, rval calls the second.
Surely most programmers would intuitively expect that behaviour? Is
there some issue there?


You're missing context. The conversation went like this:

Jonathan: `Andrei said rvalue references were a mistake in C++'

Andrei: `No, I said binding rvalues to const& was a mistake of C++, 
which subsequently led to the necessity of rvalue references.'


Atila: `Indeed, if you cannot distinguish between void fun(ref const 
Foo) and void fun(Foo) then you're going to have a bad time.'


(NOTA BENE: at this point it became unclear whether we discuss C++ or 
hypothetical D code. Atila used D syntax in a discussion about C++'s issue.)


Me: `Affirmative.'

You: `But wait, it's intuitive: lvalues bind to the first, rvalues bind 
to the last.'


Well, I'd agree it's intuitive but C++ won't allow it. These overloads 
are ambiguous in C++ code:


==
struct S {};
void foo(S);
void foo(const S&); // no error so far (which doesn't help either)

int main() {
S a;
foo(a); // ERROR! Ambiguous call!
const S b;
foo(b); // ERROR! Ambiguous call!
foo(S()); // ERROR! Ambiguous call!
extern const S goo();
foo(goo()); // ERROR! Ambiguous call!
}
==

This was C++'s big un' that led to many complications. If the overload 
weren't ambiguous, a large part of rvalue references would have been 
unneeded. (Universal references would still have been necessary for 
perfect forwarding, but that's not the bulk.)


In order to avoid such issues, we steered clear off binding rvalues to 
ref parameters in the D language. As I mentioned to Ethan, I do agree a 
careful definition may be able to avoid the fallout that happened in 
C++. It would be a fair amount of work.



Andrei

Re: gdc in Linux distros recommended?

[ketmar via Digitalmars-d]

On Wednesday, 19 October 2016 at 10:15:49 UTC, Daniel Kozak wrote:
Not true, as my previos comment mentioned almost every popular 
distro nowdays have ldc and gdc in repositories. But only few 
of them have dmd


most of the distros just can't. they with to repackage/rebuild 
it, and boom! it is forbidden. proprietary backend license 
seriously backstabbing dmd.

Re: I close BIP27. I won't be pursuing BIPs anymore

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/16 5:11 AM, Ethan Watson wrote:

On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:

People just want to be able to do this:

  void f(ref const(Vector) v);

  f(v1 + v2);

or:

  f(Vector(10,20,30));

That is all. The rval produces a temporary, and the temporary is
passed to the function.


Probably worth pointing out that we laid it out exactly like this to
Walter and Andrei at DConf, and how not having it made the Quantum Break
animation code (all of which is 3D math) a pain to write thanks to
having to define the temporary variables yourself. Especially when
you're calling bound C++ functions and the programmers involved could
compare it to C++ directly saying "Why can't we do this?"


"Because you're trying to write C++ in D." :o)

I'm just kidding. I agree it's occasionally unpleasant to have the 
calling convention impose l/rvalueness depending on by ref/by value 
signature. With the recent tightening of ref semantics, and if we 
carefully navigate around C++'s mistake, we may be able to define a way 
to meaningfully bind rvalues to ref. It's a fair amount of work, worth a 
thorough DIP. Implementation is the easy part (for the most part lifting 
restrictions).



Andrei

Re: List defined version specifications

[Basile B. via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 10:25:51 UTC, Lodovico Giaretta 
wrote:

Hi!

A simple question: is there a way to list all defined version 
specifications?


Something like:

pragma(msg, __traits(allVersions));

Example output (DMD on Ubuntu x64, release build):

[all, D_InlineAsm_X86_64, X86_64, Posix, linux, 
DigitalMars, CRuntime_Glibc, D_Version2, LittleEndian, D_LP64, 
D_HardFloat, D_SIMD, D_NoBoundsChecks, ELFv2]


Thank you in advance.


No, but they can be generated with a string mixin:

static __gshared string[] definedVersions;

enum predefinedVersions = [
"ARM_Thumb","assert","ELFv1","ELFv2",
"HPPA","HPPA64","Posix","unittest",
"Win32","Win64","Windows","X86","X86_64"
];

alias addDefinedVer = (ver) => `version(`~ ver ~`) 
definedVersions~="`

~ ver ~ `";`;

string genDefinedVersions()
{
import std.meta: aliasSeqOf;
import std.range: iota;
string result;
foreach(i; aliasSeqOf!(iota(0, predefinedVersions.length)))
result ~= addDefinedVer(predefinedVersions[i]);
return result;
}

void main()
{
mixin(genDefinedVersions);
}

The problem being that they are not available at compile time.

Re: Why are homepage examples too complicated?

[rikki cattermole via Digitalmars-d]

On 20/10/2016 12:08 AM, Andrei Alexandrescu wrote:

On 10/19/16 5:28 AM, Benjiro wrote:

No offense to Andrei, while his is funny, he is simply thinking above my
head. Walter is actually better at explain things.


None taken! And thanks for your feedback. I think you have an easy means
of helping progress here. Simply send more code snippets for the
homepage (the kind you believe would have helped you). Post them here or
aggregate them in a bugzilla issue and we'll add them to the rotating
pool. We clearly need more examples of varying difficulties. -- Andrei


On that note, maybe we should setup a 'real code' pool so people can see 
real code, preferably on a few files big that does a specific but useful 
task.

Re: std.experimental.allocator and GC.addRange

[Basile B. via Digitalmars-d-learn]

On Wednesday, 19 October 2016 at 08:34:57 UTC, Benjamin Thaut 
wrote:
Lets assume I have a allocator which cains together multiple 
building blocks from std.experimental.allocator and at the end 
there is a mallocator providing the underlying memory. Now I 
alloacte a type which contains a pointer into GC memory. 
Obviously the memory of the mallocator is not scanned by the GC 
so the pointer might become dangling if the GC chooses to 
collect. I'm wondering if std.experimental.allocator has any 
building blocks or mechanism to automatically call GC.addRange.


Kind Regards
Benjamin Thaut


No and that's a problem. There was a thread the other day about 
that:

https://forum.dlang.org/thread/iubialncuhahhxsfv...@forum.dlang.org

The problem is easily verifiable:
https://issues.dlang.org/show_bug.cgi?id=15790

The solution would be to add a static scanner in make. (the range 
must be added before the call the __ctor).

[Issue 11594] synchronized causing segfault instead of Error.

[via Digitalmars-d-bugs]

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

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--

Re: Why are homepage examples too complicated?

[Andrei Alexandrescu via Digitalmars-d]

On 10/19/16 5:28 AM, Benjiro wrote:

No offense to Andrei, while his is funny, he is simply thinking above my
head. Walter is actually better at explain things.


None taken! And thanks for your feedback. I think you have an easy means 
of helping progress here. Simply send more code snippets for the 
homepage (the kind you believe would have helped you). Post them here or 
aggregate them in a bugzilla issue and we'll add them to the rotating 
pool. We clearly need more examples of varying difficulties. -- Andrei

[Issue 16624] New: std.path.setExtension ddoc comment is strangely formated

[via Digitalmars-d-bugs]

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

  Issue ID: 16624
   Summary: std.path.setExtension ddoc comment is strangely
formated
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

The Description is after Params and Returns, should be before.

--

Re: Wait-free queue

[Dejan Lekic via Digitalmars-d]

On Tuesday, 18 October 2016 at 18:03:58 UTC, Andrei Alexandrescu 
wrote:
Interesting work: 
http://concurrencyfreaks.blogspot.com/2016/10/crturn-queue-first-mpmc-memory.html -- Andrei


I could not help but paste something from the paper: "We chose 
C++14 because

it is a native language that is supported by most recent compilers
and has a well defined memory model and atomics API, which
makes the code portable across different architectures without any
modification and without introducing CPU specific memory fences."

Conclusion:
D needs a serious document (specification) explaining the memory 
model!

Re: I close BIP27. I won't be pursuing BIPs anymore

[Walter Bright via Digitalmars-d]

Better:

   void f(ref Vector v);
   void f(Vector v) { f(v); }

   f(Vector(10,20,30));

List defined version specifications

[Lodovico Giaretta via Digitalmars-d-learn]

Hi!

A simple question: is there a way to list all defined version 
specifications?


Something like:

pragma(msg, __traits(allVersions));

Example output (DMD on Ubuntu x64, release build):

[all, D_InlineAsm_X86_64, X86_64, Posix, linux, DigitalMars, 
CRuntime_Glibc, D_Version2, LittleEndian, D_LP64, D_HardFloat, 
D_SIMD, D_NoBoundsChecks, ELFv2]


Thank you in advance.

Re: gdc in Linux distros recommended?

[Daniel Kozak via Digitalmars-d]

Dne 19.10.2016 v 12:15 Daniel Kozak napsal(a):

Dne 19.10.2016 v 12:05 bachmeier via Digitalmars-d napsal(a):


On Wednesday, 19 October 2016 at 07:37:33 UTC, qznc wrote:

On Wednesday, 19 October 2016 at 00:07:12 UTC, bachmeier wrote:

According to this page
https://gdcproject.org/downloads/
there are only distro packages for Ubuntu, Debian, and Arch. If 
that's accurate, there really is no sense in which GDC is more 
available than DMD.


Yes it is. Installing gdc is just "apt install gdc" on Ubuntu 
without looking for any download sites.


That doesn't work if you're on Fedora, opensuse, or whatever new 
distro happens to be popular this week.
Not true, as my previos comment mentioned almost every popular distro 
nowdays have ldc and gdc in repositories. But only few of them have dmd

Btw. I belive that future is in http://flatpak.org or similar concepts

Re: gdc in Linux distros recommended?

[Dejan Lekic via Digitalmars-d]

On Tuesday, 18 October 2016 at 23:02:28 UTC, Ali Çehreli wrote:

I have a friend who has started writing a library in D.

Although I recommended that he should use a recent dmd or ldc, 
he thinks gdc is a better candidate because it's "available to 
the masses" through Linux distros similar to how gcc is. 
Although he has a good point, the gdc that came with his distro 
does not even support @nogc.


Thoughts? Can you please tell him to change his mind! :p

Ali


For an example, Fedora's default repository ONLY has LDC, because 
GDC is not yet merged into GCC. The reason why Ubuntu does is 
because they have relaxed policy regarding GCC.


I think LDC is in most major distros, GDC is not, so LDC is the 
clear winner here. I build GDC myself and use it on Fedora, it is 
pretty straightforward, but I would recommend LDC to beginners. 
Once GDC is merged into GCC, it is a no-brainer - GCC/GDC all the 
way!

Re: I close BIP27. I won't be pursuing BIPs anymore

[Walter Bright via Digitalmars-d]

On 10/19/2016 2:11 AM, Ethan Watson wrote:

On Wednesday, 19 October 2016 at 05:41:17 UTC, Manu wrote:

People just want to be able to do this:

  void f(ref const(Vector) v);

  f(v1 + v2);

or:

  f(Vector(10,20,30));

That is all. The rval produces a temporary, and the temporary is passed to the
function.


Probably worth pointing out that we laid it out exactly like this to Walter and
Andrei at DConf, and how not having it made the Quantum Break animation code
(all of which is 3D math) a pain to write thanks to having to define the
temporary variables yourself. Especially when you're calling bound C++ functions
and the programmers involved could compare it to C++ directly saying "Why can't
we do this?"



  void f(ref Vector v);
  void fv(Vector v) { f(v); }

  fv(Vector(10,20,30));

fv gets inlined, so no overhead.