Re: Move construction from !is(T == typeof(this))

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 25 April 2017 at 01:59:55 UTC, Manu wrote:


Ah crap, I somehow missed the single-argument move() function.

Okay, so this pattern is definitely reliable? I haven't seen it 
clearly documented anywhere that this is the prescribed 
pattern, and it's come up on stack overflow a few times, but it 
hasn't been answered correctly.

I think this is poorly distributed knowledge.


It is definitely reliable.

As Schveighoffer pointed out, this pattern requires *another* 
overload for `ref const X`? Surely if there is no `ref X` and 
only a `ref const X` available, it should choose that one 
rather than the byval one when the argument is not const (as 
demonstrated in the bug report?)


No, the bug report is incorrect. See 
http://dlang.org/spec/function.html#function-overloading. 
Remember that, unlike C++'s '&', "ref" is not a type, it's a 
parameter storage class. So, given the overloads


foo(const ref X);
foo(X x);

or, more precisely:

foo(ref const(X));
foo(X x);

if you call foo with a non-const X lvalue *or* rvalue, the second 
overload will be chosen (the exact match):


X x;
foo(x);   // typeof(x) == X, so foo(X) is chosen. It's passed by 
value, so x is copied first.

foo(X()); // also calls foo(X), this time no copy is needed

const X cx;
foo(cx); // calls foo(ref const(X)), since typeof(cx) == const(X)

In C++, those foos would be ambiguous. In D, they aren't, because 
it first checks whether it's const or not, and then whether it's 
an lvalue or an rvalue.


It's demonstrated that `ref const X` might inhibit an efficient 
copy constructor implementation in some cases, but you can't 
have false-move's occurring when the lvalue is not const.


It's not about efficiency, it's about preserving type 
information. Once you slap "const" on, there's no getting rid of 
it without violating the type system.
And there won't be any "false" moves. You either have a reference 
to copy from, or a full-blown copy/rvalue to move from.

Re: excel-d v0.0.1 - D API to write functions callable from Excel

[Laeeth Isharc via Digitalmars-d-announce]

C++ example for XLW:

 LPXLFOPER EXCEL_EXPORT xlStats(LPXLFOPER inTargetRange) {
EXCEL_BEGIN;
XlfOper xlTargetRange(inTargetRange);

// Temporary variables.
double averageTmp = 0.0;
double varianceTmp = 0.0;

// Iterate over the cells in the incoming matrix.
for (RW i = 0; i < xlTargetRange.rows(); ++i)
{
for (RW j = 0; j < xlTargetRange.columns(); ++j)
{
// sums the values.
double value(xlTargetRange(i,j).AsDouble());
averageTmp += value;
// sums the squared values.
varianceTmp += value * value;
}
}
size_t popSize = xlTargetRange.rows() * 
xlTargetRange.columns();


// avoid divide by zero
if(popSize == 0)
{
THROW_XLW("Can't calculate stats on empty range");
}

// Initialization of the results Array oper.
XlfOper result(1, 2);
// compute average.
double average = averageTmp / popSize;
result(0, 0) = average;
// compute variance
result(0, 1) = varianceTmp / popSize - average * average;
return result;
EXCEL_END;
}

D example (didn't get time to test, but something like this) is a 
little bit more concise! :

import std.algorithm:map,sum;
import std.range:front;

@Register(ArgumentText("input range to calculate statistics 
for"),

HelpTopic("excel-d"),
FunctionHelp("calculates mean and variance for input 
array"),

ArgumentHelp(["input range to calculate statistics for"]))
auto xlStats(double[][] inTargetRange)
{
auto numCells = (inTargetRange.length > 0) ?
 inTargetRange.length * 
inTargetRange.front.length : 0;
auto means = inTargetRange.map!(row => row.sum).sum / 
numCells;
auto sumSquares = inTargetRange.map!( row => 
row.map!(cell => cell*cell).sum).sum;

return [means, sumSquares / numCells - means];
}

Re: excel-d v0.0.1 - D API to write functions callable from Excel

[Laeeth Isharc via Digitalmars-d-announce]

On Monday, 24 April 2017 at 21:59:34 UTC, Atila Neves wrote:

Now with more `@nogc`. Before, this worked fine:

double func(double d) @nogc nothrow { return d * 2; }

The function is `@nogc`, the wrapper function (i.e. the 
function that Excel actually calls) is also `@nogc` via the 
magic of compile-time reflection. So far, so good. But what if 
you want to return a string or an array back to Excel. Oh, oh...


Enter the `@Dispose` UDA:

And Bob's your uncle.

Atila


Very nice.
On reddit here since it's a pretty nice example of how you don't 
need to use dark magic to write code in D without depending on 
the GC:

https://www.reddit.com/r/programming/comments/67dogy/writing_excel_addins_in_d_without_using_the/

Re: Move construction from !is(T == typeof(this))

[Manu via Digitalmars-d]

On 25 April 2017 at 08:46, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 04/24/2017 04:23 PM, ag0aep6g wrote:
>
>> On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
>>
>>> Speaking of const violation and UB, std.algorithm.mutation.move seems to
>>> violate const without remorse:
>>>
>>
>> Yup. Even in @safe code, which is a bug.
>> https://issues.dlang.org/show_bug.cgi?id=15315
>>
>
> Should fail in all situations, thanks for reporting.
>
> The original code should work like this:
>
> struct X {}
>
> struct Y {
>   private X _x;
>   this()(auto ref X x)
>   {
> static if (__traits(isRef, x))
> {
> _x = x;
> }
> else
> {
> import std.algorithm.mutation : move;
> _x = move(x);
> }
>   }
> }
>
> Note how I made the ctor templated so it accepts auto ref. The less
> sophisticated version is simply:
>
> struct X {}
>
> struct Y {
>   private X _x;
>   this(ref X x)
>   {
>  _x = x;
>   }
>   this(X x)
>   {
>  import std.algorithm.mutation : move;
>  _x = move(x);
>   }
> }
>

Ah crap, I somehow missed the single-argument move() function.

Okay, so this pattern is definitely reliable? I haven't seen it clearly
documented anywhere that this is the prescribed pattern, and it's come up
on stack overflow a few times, but it hasn't been answered correctly.
I think this is poorly distributed knowledge.

As Schveighoffer pointed out, this pattern requires *another* overload for
`ref const X`? Surely if there is no `ref X` and only a `ref const X`
available, it should choose that one rather than the byval one when the
argument is not const (as demonstrated in the bug report?)
It's demonstrated that `ref const X` might inhibit an efficient copy
constructor implementation in some cases, but you can't have false-move's
occurring when the lvalue is not const.

Re: Move construction from !is(T == typeof(this))

[Andrei Alexandrescu via Digitalmars-d]

On 04/24/2017 07:13 PM, Stanislav Blinov wrote:

On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu wrote:

On 04/24/2017 04:23 PM, ag0aep6g wrote:

On 04/24/2017 08:48 PM, Stanislav Blinov wrote:

Speaking of const violation and UB, std.algorithm.mutation.move
seems to
violate const without remorse:


Yup. Even in @safe code, which is a bug.
https://issues.dlang.org/show_bug.cgi?id=15315


Should fail in all situations, thanks for reporting.


So, basically any type with const/immutable members effectively becomes
immovable?


If the type moved from has no elaborate postblit, a move is the same as 
a copy so those should work.



I'll make the PR.


Thanks!


Andrei

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

--- Comment #3 from Andrei Alexandrescu  ---
Indeed, apologies. The target cannot be immutable.

--

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Wait, what? Aren't *both* k1.id and k2.id *immutable*?  How could move(k2,k1)
be valid, since it would overwrite k1, which violates the immutability of
k1.id?

--

Re: Move construction from !is(T == typeof(this))

[Stanislav Blinov via Digitalmars-d]

On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu 
wrote:

On 04/24/2017 04:23 PM, ag0aep6g wrote:

On 04/24/2017 08:48 PM, Stanislav Blinov wrote:
Speaking of const violation and UB, 
std.algorithm.mutation.move seems to

violate const without remorse:


Yup. Even in @safe code, which is a bug.
https://issues.dlang.org/show_bug.cgi?id=15315


Should fail in all situations, thanks for reporting.


So, basically any type with const/immutable members effectively 
becomes immovable?


There should be ways to do this easier, i.e. add a forward() 
function to std.algorithm.mutation. Contributions are welcome!


Ah, thanks for the hint. There actually is one in std.functional, 
but it's not designed to handle one-argument situations well 
(returns a tuple instead of forwarding the argument). This works:


import std.algorithm.mutation : move;

template forward(args...)
{
import std.meta;

static if (args.length)
{
static if (__traits(isRef, args[0]))
alias fwd = args[0];
else
@property fwd() { return move(args[0]); }

static if (args.length == 1)
alias forward = fwd;
else
alias forward = AliasSeq!(fwd, forward!(args[1..$]));
}
else alias forward = AliasSeq!();
}

struct Y
{
private X _x;
this()(auto ref X x)
{
_x = forward!x;
}
}

struct X {
this(this) { writeln("copy"); }
}

void main()
{
X x;
Y y = x;// outputs "copy"
Y y2 = move(x); // moves, postblit not called
}

I'll make the PR.

Re: Move construction from !is(T == typeof(this))

[Andrei Alexandrescu via Digitalmars-d]

On 04/24/2017 04:23 PM, ag0aep6g wrote:

On 04/24/2017 08:48 PM, Stanislav Blinov wrote:

Speaking of const violation and UB, std.algorithm.mutation.move seems to
violate const without remorse:


Yup. Even in @safe code, which is a bug.
https://issues.dlang.org/show_bug.cgi?id=15315


Should fail in all situations, thanks for reporting.

The original code should work like this:

struct X {}

struct Y {
  private X _x;
  this()(auto ref X x)
  {
static if (__traits(isRef, x))
{
_x = x;
}
else
{
import std.algorithm.mutation : move;
_x = move(x);
}
  }
}

Note how I made the ctor templated so it accepts auto ref. The less 
sophisticated version is simply:


struct X {}

struct Y {
  private X _x;
  this(ref X x)
  {
 _x = x;
  }
  this(X x)
  {
 import std.algorithm.mutation : move;
 _x = move(x);
  }
}

There should be ways to do this easier, i.e. add a forward() function to 
std.algorithm.mutation. Contributions are welcome!



Andrei

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
This should pass regardless of safe. The move function should simply copy the
integer without overwriting it. This is because int does not have an elaborate
postblit so it is cheap to copy.

--

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Vasudev Ram via Digitalmars-d]

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote:

Hi list,

I hope the question is self-evident from the message subject. 
If not, it means: what are D developers generally called (to 
indicate that they develop in D)? The question occurred to me 
somehow while browsing some D posts on the forums just now.


DLanger? DLangist? D'er? Doer? :)

I tend to favor DLanger, FWIW.

Interested to know, just for fun ...

I do realize that there may not be commonly known or accepted 
terms like this for all languages. For example, I don't know if 
there is such a term for a C or C++ developer. Might make for 
an interesting thread.


Cheers,
Vasudev
Site: https://vasudevram.github.io
Dlang posts: https://jugad2.blogspot.com/search/label/dlang
Python posts: https://jugad2.blogspot.com/search/label/python


I was reading some of the replies over the last few days, have 
replied to a couple of them, and saw some more.


Enjoyed reading some of the responses that were in the same fun 
and innocuous spirit in which I wrote the post. (The D-series of 
terms, I mean - cool and creative, guys :)


Was surprised by some of the other reactions, many of which are 
probably due to misinterpretation of what I wrote. Will be 
replying to some more comments, as I think is needed, in a couple 
of days, but meanwhile, some of those commenters may find 
something to think about (w.r.t. to claims or "deductions" they 
have made about (their) perceived meaning of my original post), 
in this article, an interview of me from over a year ago:


https://www.blog.pythonlibrary.org/2015/05/18/pydev-of-the-week-vasudev-ram/

In particular, pay specific attention to my replies to the 
interviewer about favorite  programming languages, and see how 
well (not!) that correlates with claims or "deductions" that you 
made here.

Re: DIP 1007 Preliminary Review Round 1

[Atila Neves via Digitalmars-d]

On Monday, 24 April 2017 at 15:22:15 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:

DIP 1007 is titled "'future symbol' Compiler Concept".


«In all the mentioned languages but D, a common convention is 
to only use unqualified access for symbols in the standard 
library.»


Not quite right for C++. The common convention in modern C++ is 
to use full std::name qualification for the standard library. 
It is common to use unqualified access for the local 
namespace(s) only.


In headers. Not in source files, and I don't know why anyone 
would want to keep typing `std::` all the time. Do some people do 
what you're describing? Yes, but I see no evidence that that's 
the common convention in modern C++. In fact, from the core 
guidelines:


"
# Example

#include
#include
#include
#include
#include

using namespace std;

// ...

Here (obviously), the standard library is used pervasively and 
apparently no other library is used, so requiring `std::` 
everywhere could be distracting."


Never mind the monstrosity that would be trying to use the C++ 
user-defined literal without `using namespace std`:


#include 
using namespace std::operator""s;  // Argh! My eyes!

No thanks. I even had to look that up, and I'll probably forget 
it.

Re: excel-d v0.0.1 - D API to write functions callable from Excel

[Atila Neves via Digitalmars-d-announce]

On Monday, 20 March 2017 at 20:09:58 UTC, Atila Neves wrote:

http://code.dlang.org/packages/excel-d

This dub package allows D code to be called from Excel. It uses 
compile-time reflection to register the user's code in an XLL 
(a DLL loaded by Excel) so no boilerplate is necessary. Not 
even `DllMain`! It works like this:


main.d:

import xlld;
mixin(wrapAll!(__MODULE__, "funcs"));

funcs.d:

import xlld;

@Register(ArgumentText("Array to add"),
  HelpTopic("Adds all cells in an array"),
  FunctionHelp("Adds all cells in an array"),
  ArgumentHelp(["The array to add"]))
double FuncAddEverything(double[][] args) nothrow @nogc {
import std.algorithm: fold;
import std.math: isNaN;

double ret = 0;
foreach(row; args)
ret += row.fold!((a, b) => b.isNaN ? 0.0 : a + b)(0.0);
return ret;
}

This code, once compiled to an XLL (see the example in the 
repository) and loaded in Excel, will permit a user to write 
`=FuncAddEverything(B1:D6)` and have the cell populated with 
the sum of all arguments in that range.


There's a lot going on behind the scenes, and that's the point. 
For instance, the function above takes a 2d array of doubles 
and returns a double, but those aren't Excel types. The wrapper 
code writes out an Excel-compatible type signature at 
compile-time, does all the conversions, calls the user's code 
then converts back to types Excel can understand.


The user functions have to be `nothrow`. This is guaranteed at 
compile-time and the user gets a warning message about the 
function not being considered. `@nogc` is optional but won't 
work if returning a string due to allocations. The code is 
compatible with std.experimental.allocator internally but 
there's no way to specify an allocator currently for the 
registration.


I can make the registration mixin easier to use but haven't 
gotten around to it yet. I thought it was better to put the 
code out there as is than wait.


This is another one of those "only in D" packages due to the 
metaprogramming, which is always nice.


Atila


Now with more `@nogc`. Before, this worked fine:

double func(double d) @nogc nothrow { return d * 2; }

The function is `@nogc`, the wrapper function (i.e. the function 
that Excel actually calls) is also `@nogc` via the magic of 
compile-time reflection. So far, so good. But what if you want to 
return a string or an array back to Excel. Oh, oh...


Enter the `@Dispose` UDA:


// @Dispose is used to tell the framework how to free memory that 
is dynamically
// allocated by the D function. After returning, the value is 
converted to an
// Excel type sand the D value is freed using the lambda defined 
here.

@Dispose!((ret) {
import std.experimental.allocator.mallocator: Mallocator;
import std.experimental.allocator: dispose;
Mallocator.instance.dispose(ret);
})
double[] FuncReturnArrayNoGc(double[] numbers) @nogc @safe 
nothrow {

import std.experimental.allocator.mallocator: Mallocator;
import std.experimental.allocator: makeArray;
import std.algorithm: map;

try {
// Allocate memory here in order to return an array of 
doubles.

// The memory will be freed after the call by calling the
// function in `@Dispose` above
return Mallocator.instance.makeArray(numbers.map!(a => a 
* 2));

} catch(Exception _) {
return [];
}
}

And Bob's your uncle.

Atila

Re: Algebra With Types

[David Sanders via Digitalmars-d-learn]

On Friday, 21 April 2017 at 20:49:27 UTC, Meta wrote:

On Friday, 21 April 2017 at 18:54:38 UTC, David Sanders wrote:

[...]


As an aside, there's a less convoluted way to do type-level 
arithmetic which is IMO also more concise and looks nicer. You 
don't have to mess around with Algebraic at all:


struct Zero;

struct Succ(N);

alias One = Succ!Zero;

alias Pred(N: Zero)= Zero;
alias Pred(N: Succ!Np, Np) = Np;

alias Add(N1: Zero, N2: Zero) = Zero;
alias Add(N1,   N2: Zero) = N1;
alias Add(N1: Zero, N2)   = N2;
alias Add(N1,   N2)   = Add!(Succ!N1, Pred!N2);

void main()
{
static assert(is(Pred!One == Zero));
static assert(is(Succ!One == Succ!(Succ!Zero)));

static assert(is(Add!(Zero, Zero) == Zero));
static assert(is(Add!(Zero, One) == One));
static assert(is(Add!(One, Zero) == One));
static assert(is(Add!(One, One) == Succ!(Succ!(Zero;

alias Two = Succ!One;
static assert(is(Add!(One, One) == Two));
static assert(is(Add!(One, Two) == 
Succ!(Succ!(Succ!Zero;


static assert(is(Sub!(Zero, Zero) == Zero));
static assert(is(Sub!(One, Zero) == One));
static assert(is(Sub!(Zero, One) == Zero));
static assert(is(Sub!(Two, One) == One));
static assert(is(Sub!(One, Two) == Zero));
}

Implementing Mul, Div and the integer set is an exercise left 
to the reader.


What you've implemented is similar to the Church encoding for 
natural numbers. I'm not trying to encode natural numbers.


I'm trying to investigate the algebra of "adding", "multiplying", 
and "raising to a power" various data types. Adding the int type 
with the char type corresponds to Algebraic!(int, char). 
Multiplying the int type by the char type corresponds to 
Tuple!(int, char). Raising the int type to the char type 
corresponds to a function that accepts a char and returns an int. 
See the blog post in my original forum post for examples.


Thanks,
Dave

Re: Address of UFCS call implicity converts to Delegate

[Jonathan Marler via Digitalmars-d]

On Monday, 24 April 2017 at 19:19:27 UTC, Meta wrote:

On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote:
I've added a DIP for this 
(https://github.com/dlang/DIPs/pull/61).


At first I first thought that all we needed was to add 
semantics to take the address of a UFCS-style call, but after 
messing around with your example I realized that delegates are 
not ABI-compatible with functions that take the delegate ptr 
as the first parameter.  You mentioned that the problem was 
with the parameter order and that this should work with 
extern(C) functions and I think you're right.


The new DIP proposes the addition of "Extension Methods" which 
are functions that are ABI-compatible with delegates. You 
define an extension method by naming the first parameter 
"this":


struct Foo
{
void bar(int x)
{
}
}
void baz(ref Foo this, int x)
{
}

Because the first parameter of baz is named this, it is an 
"extension method" of Foo which means it is ABI-compatible 
with the method bar.


void delegate(int x) dg;
Foo foo;

dg =   // a normal method delegate
dg(42); // calls foo.bar(42)

dg =   // an extension method delegate
dg(42); // calls baz(foo, 42);

dg =   // a "null delegate", unsafe code, funcptr 
points to the baz function, but ptr is null

dg(42); // calls baz(null, 42);


One small tweak is that `this` should act as a storage class 
instead of the user having to name the parameter `this`. This 
is what C# does so we should mimic it to avoid confusion.


https://www.codeproject.com/Tips/709310/Extension-Method-In-Csharp


Yes I'm familiar with C# extension methods and that was my 
initial thought. The one advantage I saw with naming the 
parameter "this" was that it produces more "refactorable" code.  
If the first parameter of a delegateable function is a reference 
to a struct or a class, then you could move the function inside 
the struct/class, take out the first parameter and the code will 
work as a member function with no changes since the "this" 
keyword will be referring to the same object in both cases.  But 
it's not a big deal, either syntax works fine in my opinion.

Re: Move construction from !is(T == typeof(this))

[ag0aep6g via Digitalmars-d]

On 04/24/2017 08:48 PM, Stanislav Blinov wrote:

Speaking of const violation and UB, std.algorithm.mutation.move seems to
violate const without remorse:


Yup. Even in @safe code, which is a bug. 
https://issues.dlang.org/show_bug.cgi?id=15315

[Issue 17346] Inconsistent l/rvalue overload resolution

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
It does work with inout.

Perhaps the reason it doesn't work is because it might view calling Y1(x1_lval)
as Y1(cast(const)x1_lval)

which seems to be an rvalue. But clearly there is no double indirection here,
and if you remove the non-ref constructor, the const ref one is then chosen.

--

[Issue 15315] can break immutable with std.algorithm.move

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||safe

--

Re: Move construction from !is(T == typeof(this))

[Steven Schveighoffer via Digitalmars-d]

On 4/24/17 2:48 PM, Stanislav Blinov wrote:

On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote:


If you're going to pinch the guts of rvalue arguments, then this needs to
be 100% reliable.
This needs to be aggressively unit-tested, and probably documented that
this is the official pattern for rvalue construction/assignment
operations.


Looking over your OP again, and the report made by Petar Kirov, I
realized this is not quite right. We can't, generally speaking, treat
this(const ref X x) as a copy ctor.

Consider:

struct X
{
int* ptr;
}

struct Y
{
int* ptr;

this(ref const X x)
{
// ptr == ???;
// typeof(x.ptr) == const(int*)
// seems like the only way to implement this is:
// ptr = new int(*x.ptr);
}

this(X x)
{
import std.algorithm.mutation : swap;
swap(ptr, x.ptr);
}
}

X x;
Y y = x; // this(ref const X) is called

Suddenly, we can't copy the pointer, or at least make a shallow copy of
it, without violating const, and the latter is UB.


This is what inout is for. I'll update the bug report.

-Steve

Re: COM Expertise needed: COM Callbacks

[Nierjerson via Digitalmars-d-learn]

On Monday, 24 April 2017 at 17:31:09 UTC, MGW wrote:

On Monday, 24 April 2017 at 00:55:45 UTC, Nierjerson wrote:

Still trying to get the com automation code working. This is a


Please, use ZIP for archive.


http://s000.tinyupload.com/index.php?file_id=67286353487198133918

Re: Address of UFCS call implicity converts to Delegate

[Meta via Digitalmars-d]

On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote:
I've added a DIP for this 
(https://github.com/dlang/DIPs/pull/61).


At first I first thought that all we needed was to add 
semantics to take the address of a UFCS-style call, but after 
messing around with your example I realized that delegates are 
not ABI-compatible with functions that take the delegate ptr as 
the first parameter.  You mentioned that the problem was with 
the parameter order and that this should work with extern(C) 
functions and I think you're right.


The new DIP proposes the addition of "Extension Methods" which 
are functions that are ABI-compatible with delegates. You 
define an extension method by naming the first parameter "this":


struct Foo
{
void bar(int x)
{
}
}
void baz(ref Foo this, int x)
{
}

Because the first parameter of baz is named this, it is an 
"extension method" of Foo which means it is ABI-compatible with 
the method bar.


void delegate(int x) dg;
Foo foo;

dg =   // a normal method delegate
dg(42); // calls foo.bar(42)

dg =   // an extension method delegate
dg(42); // calls baz(foo, 42);

dg =   // a "null delegate", unsafe code, funcptr 
points to the baz function, but ptr is null

dg(42); // calls baz(null, 42);


One small tweak is that `this` should act as a storage class 
instead of the user having to name the parameter `this`. This is 
what C# does so we should mimic it to avoid confusion.


https://www.codeproject.com/Tips/709310/Extension-Method-In-Csharp

Re: Move construction from !is(T == typeof(this))

[Stanislav Blinov via Digitalmars-d]

On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote:

If you're going to pinch the guts of rvalue arguments, then 
this needs to

be 100% reliable.
This needs to be aggressively unit-tested, and probably 
documented that
this is the official pattern for rvalue construction/assignment 
operations.


Looking over your OP again, and the report made by Petar Kirov, I 
realized this is not quite right. We can't, generally speaking, 
treat this(const ref X x) as a copy ctor.


Consider:

struct X
{
int* ptr;
}

struct Y
{
int* ptr;

this(ref const X x)
{
// ptr == ???;
// typeof(x.ptr) == const(int*)
// seems like the only way to implement this is:
// ptr = new int(*x.ptr);
}

this(X x)
{
import std.algorithm.mutation : swap;
swap(ptr, x.ptr);
}
}

X x;
Y y = x; // this(ref const X) is called

Suddenly, we can't copy the pointer, or at least make a shallow 
copy of it, without violating const, and the latter is UB.
The ref const overload should only be called with const lvalues, 
and it seems to be the case.
OTOH, copying with this(ref X x) will work, as will this(X), so I 
guess the proper set of overloads should be:


struct Y
{
this(ref X x) { /*copy...*/ }
this(X x) { /*move...*/ }
}

with possible addition of this(ref const X x) for a deep copy.

Speaking of const violation and UB, std.algorithm.mutation.move 
seems to violate const without remorse:


struct Z
{
const int i;

~this() {}
}

auto z = Z(10);
auto zz = move(z);
// z.i is now 0

So, move does set z to a default-constructed state, but in doing 
so changes the value of a const variable. And there seems to be 
no other way to implement destructive move.
In case of such Z, of course the only thing you can safely do 
with z now is destruct it (not that the language can enforce it), 
so we might say it's all good...

Re: Vibed + osv.io

[Dmitry Olshansky via Digitalmars-d]

On 4/24/17 5:17 PM, Suliman wrote:

On Monday, 24 April 2017 at 15:10:29 UTC, Suliman wrote:

I have found very interesting project http://osv.io
Has anybody to use it with vibed? I am not sure if it's
yet-another-linux distrib or OS written from scratch.


As they mention it from the get go - it's a new OS build from the ground 
up to be operated under hypervisor.




I found link on Redox page https://github.com/redox-os/redox/issues/925

It would be nice to have way to get run vibed from something very
lightweight.


Am I right understand that if Redox have port of libc it would be
possible to write D apps for Redox?


Currently D relies on GLIBC far as I can tell, doing a port to anther 
libc is certainly doable.


---
Dmitry Olshansky

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Timon Gehr via Digitalmars-d-announce]

On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote:

On 04/24/2017 11:17 AM, Timon Gehr wrote:

Also, Java's type system is
unsound.



Not doubting you, but this sounds interesting. Further info or links?


https://dev.to/rosstate/java-is-unsound-the-industry-perspective

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

[Stefan Koch via Digitalmars-d]

On Monday, 24 April 2017 at 11:29:01 UTC, Ola Fosheim Grøstad 
wrote:


What are scaled loads?


x86 has addressing modes which allow you to multiply an index by 
a certain set of scalars and add it as on offset to the pointer 
you want to load.
Thereby making memory access patterns more transparent to the 
caching and prefetch systems.

As well as reducing the overall code-size.

Re: COM Expertise needed: COM Callbacks

[MGW via Digitalmars-d-learn]

On Monday, 24 April 2017 at 00:55:45 UTC, Nierjerson wrote:

Still trying to get the com automation code working. This is a


Please, use ZIP for archive.

Re: Address of UFCS call implicity converts to Delegate

[Jonathan Marler via Digitalmars-d]

On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote:

On Sunday, 23 April 2017 at 17:13:31 UTC, Basile B. wrote:

[...]


I've added a DIP for this 
(https://github.com/dlang/DIPs/pull/61).


At first I first thought that all we needed was to add 
semantics to take the address of a UFCS-style call, but after 
messing around with your example I realized that delegates are 
not ABI-compatible with functions that take the delegate ptr as 
the first parameter.  You mentioned that the problem was with 
the parameter order and that this should work with extern(C) 
functions and I think you're right.


The new DIP proposes the addition of "Extension Methods" which 
are functions that are ABI-compatible with delegates. You 
define an extension method by naming the first parameter "this":

[...]


Scratch the "Extension Methods" idea.  I've found a more 
generalized way to do the same thing.  I'm calling it 
"Delegateable Functions" (https://github.com/dlang/DIPs/pull/61).

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

[Jonathan Marler via Digitalmars-d]

On Monday, 24 April 2017 at 14:41:44 UTC, jmh530 wrote:

On Monday, 24 April 2017 at 12:59:55 UTC, Jonathan Marler wrote:


Have you considered using the LLVM jit compiler for CTFE? We 
already have an LLVM front end. This would mean that CTFE 
would depend on LLVM, which is a large dependency, but it 
would create very fast, optimized code for CTFE on any 
platform.




I can't help but laugh at this after the above posts...


I totally missed when Stefan said:

Also and perhaps more importantly I am sick and tired of 
hearing "why don't you use ldc/llvm?" all the time...


That is pretty hilarious :)  I suppose I just demonstrated the 
reason he is attempting to create an x86 jitter so he will have 
an interface that could be extended to something like LLVM.  Wow.

Re: GC: Understanding potential sources of false pointers

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

On 04/22/2017 08:56 AM, Kagamin wrote:

.rdata is fine, but afaik you have only strings there, the rest - .data,
.bss, .tls will suffer the same issue.


I don't know anything about the various object file sections. :/

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Nick Sabalausky (Abscissa) via Digitalmars-d-announce]

On 04/24/2017 11:17 AM, Timon Gehr wrote:

Also, Java's type system is
unsound.



Not doubting you, but this sounds interesting. Further info or links?

Re: multiple `alias this` suggestion

[Carl Sturtivant via Digitalmars-d]

On Friday, 21 April 2017 at 14:51:42 UTC, Meta wrote:

auto x = top(1,2,3);

void takesMember1(member1) {}
void takesMember2(member2) {}
void takesMember3(member3) {}

static assert(__traits(compiles, { takesMember1(x); }));  
//Passes
static assert(__traits(compiles, { takesMember2(x); })); 
//Passes
static assert(__traits(compiles, { takesMember3(x); })); 
//Passes


This is a little bit surprising until you think about it a bit. 
It's also how we would want multiple alias this to behave were 
it implemented, which is a plus.


Nice!

Re: multiple `alias this` suggestion

[Carl Sturtivant via Digitalmars-d]

On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer 
wrote:
I agree, I like how this solves the ambiguity problem nicely. 
However, this disallows using introspection to declare multiple 
alias this piecemeal. e.g.:


struct S(bool foo)
{
  int x;
  alias x this;
  static if(foo)
  {
 string y;
 alias y this;
  }
}

One thing we can do also is just use declaration order to 
prioritize which alias this to use.


Not necessary in this case:

struct S(bool foo)
{
  int x;
  static if(!foo)
  {
 alias x this;
  }
  else
  {
 string y;
 alias x, y this;
  }
}

It's easier to analyze if  isn't distributed, i.e. if only one 
location applies.

How to overload member function pointer and a regualr member function

[ParticlePeter via Digitalmars-d-learn]

I would like to have this kind of struct:

struct Foo {
  private int i;
  void function( int i, float f ) bar;  // will be defined at 
runtime

  void bar( float f ) {
bar( i, f );
  }
}

But apparently the function pointer and the member function 
cannot have the same name: Error: function main.Foo.bar conflicts 
with variable main.Foo.bar ...


I tried with an inner struct:
struct Foo {
  private int i;
  void function( int i, float f ) bar;  // will be defined at 
runtime

  private struct Inner {
void bar( float f ) {
  bar( i, f );
}
  }
  Inner inner;
}

But this time I get following error:
Error: need 'this' for 'i' of type 'int'

What does this message tell me? Should the inner struct not be 
able to access Foo.i?


How else can I get the required behavior?

I would prefer to avoid another indirection like this:
struct Foo {
  private int i;
  void function( int i, float f ) bar;  // will be defined at 
runtime

  void baz( float f ) {
bar( i, f );
  }
  void baz( int ii, float f ) {
bar( ii, f );
  }
}

[Issue 17347] DMD generates different (and wrong) output in -release mode

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ag0ae...@gmail.com
 Resolution|--- |DUPLICATE

--- Comment #1 from ag0ae...@gmail.com ---
For me, the code misbehaves even without -release. I get
"core.exception.SwitchError@test(15): No appropriate switch clause found".

As far as I can tell, this is a duplicate of issue 15538. I'm marking this as
such. Please revert if there's a difference I'm missing.

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

--

[Issue 15538] wrong code with switch

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||alexander.brec...@gmail.com

--- Comment #6 from ag0ae...@gmail.com ---
*** Issue 17347 has been marked as a duplicate of this issue. ***

--

Re: DIP 1007 Preliminary Review Round 1

[rikki cattermole via Digitalmars-d]

On 24/04/2017 4:03 PM, Mike Parker wrote:

DIP 1007 is titled "'future symbol' Compiler Concept".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md

All review-related feedback on and discussion of the DIP should occur in
this thread. Due to DConf taking place during the review period, the
period will be extended by a week. The review period will end at 11:59
PM ET on May 15 (3:59 AM GMT May 16), or when I make a post declaring it
complete.

At the end of Round 1, if further review is deemed necessary, the DIP
will be scheduled for another round. Otherwise, it will be queued for
the formal review and evaluation by the language authors.

Thanks in advance to all who participate.

Destroy!


This DIP concerns me, for any other language I would go so far as to 
saying, I would expect people to overuse this to the extreme. Going by 
what they "think" they may need in the future instead of what they 
definitely will need.


On the flip side, it would be great for development, feature not yet 
done but planned? Annotate it. Even before a release ever happens.


Although I would prefer to see a unifying syntax to merge deprecated and 
this into it, making it more user configurable. More complex to design 
but most importantly less special rules in language.

[Issue 17347] New: DMD generates different (and wrong) output in -release mode

[via Digitalmars-d-bugs]

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

  Issue ID: 17347
   Summary: DMD generates different (and wrong) output in -release
mode
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alexander.brec...@gmail.com

The following snippet correctly prints "0" when compiled with dmd (no -release)
or ldc. However, adding -release prints a weird value. The value is slightly
different for each run, but stays in the same number region.

DMD64 D Compiler v2.074.0 (ArchLinux)

$ dmd -release app.d && ./app
140734704773424

I was not able to further reduce the code, as changing seemingly unimportant
things, like removing the "number" field from Wrapper, "fixes" the issue:

import std.stdio;

void main() {
writeln(f(Wrapper(ABCD.B, 1)).length);
}

enum ABCD { A, B, C, D }

struct Wrapper {
ABCD abcd;
uint number;
}

bool[] f(Wrapper x) {
final switch(x.abcd) {
case ABCD.A:
case ABCD.B:
case ABCD.C:
case ABCD.D:
return [];
}
}



Here's the relevant output of objdump -D, just in case it helps:

0043abc8 <_Dmain>:
  43abc8:55   push   %rbp
  43abc9:48 8b ec mov%rsp,%rbp
  43abcc:48 83 ec 10  sub$0x10,%rsp
  43abd0:c7 45 f8 01 00 00 00 movl   $0x1,-0x8(%rbp)
  43abd7:c7 45 fc 01 00 00 00 movl   $0x1,-0x4(%rbp)
  43abde:48 8b 7d f8  mov-0x8(%rbp),%rdi
  43abe2:e8 0d 00 00 00   callq  43abf4 <_D3app1fFS3app7WrapperZAb>
  43abe7:48 89 c7 mov%rax,%rdi
  43abea:e8 41 00 00 00   callq  43ac30
<_D3std5stdio14__T7writelnTmZ7writelnFNfmZv>
  43abef:31 c0xor%eax,%eax
  43abf1:c9   leaveq 
  43abf2:c3   retq   
...

0043abf4 <_D3app1fFS3app7WrapperZAb>:
  43abf4:55   push   %rbp
  43abf5:48 8b ec mov%rsp,%rbp
  43abf8:48 83 ec 10  sub$0x10,%rsp
  43abfc:48 89 7d f8  mov%rdi,-0x8(%rbp)
  43ac00:48 83 ff 03  cmp$0x3,%rdi
  43ac04:77 26ja 43ac2c
<_D3app1fFS3app7WrapperZAb+0x38>
  43ac06:48 8d 05 33 fb 02 00 lea0x2fb33(%rip),%rax# 46a740
<_IO_stdin_used+0x10>
  43ac0d:48 63 0c b8  movslq (%rax,%rdi,4),%rcx
  43ac11:48 8d 04 01  lea(%rcx,%rax,1),%rax
  43ac15:ff e0jmpq   *%rax
  43ac17:31 f6xor%esi,%esi
  43ac19:48 8d 3d 20 40 24 00 lea0x244020(%rip),%rdi#
67ec40 <_D11TypeInfo_Ab6__initZ>
  43ac20:e8 0f 22 00 00   callq  43ce34 <_d_arrayliteralTX>
  43ac25:48 89 c2 mov%rax,%rdx
  43ac28:31 c0xor%eax,%eax
  43ac2a:c9   leaveq 
  43ac2b:c3   retq   
  43ac2c:c9   leaveq 
  43ac2d:c3   retq   
...

--

Re: Address of UFCS call implicity converts to Delegate

[Jonathan Marler via Digitalmars-d]

On Sunday, 23 April 2017 at 17:13:31 UTC, Basile B. wrote:

On Sunday, 23 April 2017 at 17:07:51 UTC, Jonathan Marler wrote:

On Sunday, 23 April 2017 at 17:00:59 UTC, Basile B. wrote:

2/ Why not just a member function ?


For the same reason that UFCS exists.  You can't add "member 
functions" to external library types.


Good point. I have to say that this feature then makes me think 
to what's called "class helpers" in the Delphi/Object Pascal 
world. That's exactly for what they're used.


I've added a DIP for this (https://github.com/dlang/DIPs/pull/61).

At first I first thought that all we needed was to add semantics 
to take the address of a UFCS-style call, but after messing 
around with your example I realized that delegates are not 
ABI-compatible with functions that take the delegate ptr as the 
first parameter.  You mentioned that the problem was with the 
parameter order and that this should work with extern(C) 
functions and I think you're right.


The new DIP proposes the addition of "Extension Methods" which 
are functions that are ABI-compatible with delegates. You define 
an extension method by naming the first parameter "this":


struct Foo
{
void bar(int x)
{
}
}
void baz(ref Foo this, int x)
{
}

Because the first parameter of baz is named this, it is an 
"extension method" of Foo which means it is ABI-compatible with 
the method bar.


void delegate(int x) dg;
Foo foo;

dg =   // a normal method delegate
dg(42); // calls foo.bar(42)

dg =   // an extension method delegate
dg(42); // calls baz(foo, 42);

dg =   // a "null delegate", unsafe code, funcptr points 
to the baz function, but ptr is null

dg(42); // calls baz(null, 42);

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote:

Swift allows raw pointer manipulation.


I didn't know that Swift had that as a language construct. Link? 
I know that it provides library solutions for raw pointers, but 
that can be said for most languages.



Java implementations expose similar unsafe features.


You think so?

Re: DIP 1007 Preliminary Review Round 1

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote:

DIP 1007 is titled "'future symbol' Compiler Concept".


«In all the mentioned languages but D, a common convention is to 
only use unqualified access for symbols in the standard library.»


Not quite right for C++. The common convention in modern C++ is 
to use full std::name qualification for the standard library. It 
is common to use unqualified access for the local namespace(s) 
only.

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Timon Gehr via Digitalmars-d-announce]

On 24.04.2017 13:33, Ola Fosheim Grøstad wrote:

On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:

The trouble is, one cannot look at a piece of code and tell if it
follows the rules or not.

I.e. it's not about it being possible to write memory safe code in C
or C++ (it is), it's about verifying an arbitrary piece of code as
being memory safe.


I don't think D and Rust fare any better than modern C++ as far as
ARBITRARY code goes. Swift and Java does...


Swift allows raw pointer manipulation. Java implementations expose 
similar unsafe features. JVMs have bugs. Also, Java's type system is 
unsound.

Re: DIP 1007 Preliminary Review Round 1

[Mike Parker via Digitalmars-d-announce]

On Monday, 24 April 2017 at 15:14:44 UTC, Mike Parker wrote:

DIP 1006 is titled "'future symbol' Compiler Concept". This


Apologies, this is DIP 1007, not 1006.

Re: Vibed + osv.io

[Suliman via Digitalmars-d]

On Monday, 24 April 2017 at 15:10:29 UTC, Suliman wrote:

I have found very interesting project http://osv.io
Has anybody to use it with vibed? I am not sure if it's 
yet-another-linux distrib or OS written from scratch.


I found link on Redox page 
https://github.com/redox-os/redox/issues/925


It would be nice to have way to get run vibed from something 
very lightweight.


Am I right understand that if Redox have port of libc it would be 
possible to write D apps for Redox?

Re: Move construction from !is(T == typeof(this))

[Manu via Digitalmars-d]

On 25 April 2017 at 00:00, Steven Schveighoffer via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:
>
> I wonder if this overload set could be made to work such that it is
>> certain that the non-ref overload is only called with rvalues; ie, given
>> this ambiguous call, ref is preferred for lvalues. rval can not call
>> ref, therefore must resolve to byval.
>>
>
> AFAIK, if you have an overload that varies solely on ref, then rvalues go
> to the non-ref and lvalues go to the ref. If this is not the case, it's
> *intended* to be the case, and should be filed as a bug.
>
> auto ref just templates that. And in your case, it's actually clearer and
> cleaner not to use auto ref.
>
> Not sure if this answers your question, or if it turns out to be a viable
> solution.
>

If you're going to pinch the guts of rvalue arguments, then this needs to
be 100% reliable.
This needs to be aggressively unit-tested, and probably documented that
this is the official pattern for rvalue construction/assignment operations.

DIP 1007 Preliminary Review Round 1

[Mike Parker via Digitalmars-d-announce]

DIP 1006 is titled "'future symbol' Compiler Concept". This 
announcement kicks off the first round of preliminary reviews. 
The review thread can be found in the General forum at:


http://forum.dlang.org/post/hjdstwzhcbrektlij...@forum.dlang.org

Please also remember that the first preliminary review of DIP 
1006 is ending in two days.


http://forum.dlang.org/thread/rsafosvkhxddkxpta...@forum.dlang.org

And that the preliminary review of DIP 1005 is also under way.

http://forum.dlang.org/thread/ckqhwodtjgpcqklcy...@forum.dlang.org

The next new DIP review is tentatively scheduled to begin on May 
1st.

Vibed + osv.io

[Suliman via Digitalmars-d]

I have found very interesting project http://osv.io
Has anybody to use it with vibed? I am not sure if it's 
yet-another-linux distrib or OS written from scratch.


I found link on Redox page 
https://github.com/redox-os/redox/issues/925


It would be nice to have way to get run vibed from something very 
lightweight.

DIP 1007 Preliminary Review Round 1

[Mike Parker via Digitalmars-d]

DIP 1007 is titled "'future symbol' Compiler Concept".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md

All review-related feedback on and discussion of the DIP should 
occur in this thread. Due to DConf taking place during the review 
period, the period will be extended by a week. The review period 
will end at 11:59 PM ET on May 15 (3:59 AM GMT May 16), or when I 
make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, the 
DIP will be scheduled for another round. Otherwise, it will be 
queued for the formal review and evaluation by the language 
authors.


Thanks in advance to all who participate.

Destroy!

Re: Move construction from !is(T == typeof(this))

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 24 April 2017 at 13:18:41 UTC, Manu wrote:
I've done that too, but that's a seriously shit solution. You 
didn't comment on any of my actual questions ;)


It answered your first question :)

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

[jmh530 via Digitalmars-d]

On Monday, 24 April 2017 at 12:59:55 UTC, Jonathan Marler wrote:


Have you considered using the LLVM jit compiler for CTFE? We 
already have an LLVM front end. This would mean that CTFE would 
depend on LLVM, which is a large dependency, but it would 
create very fast, optimized code for CTFE on any platform.




I can't help but laugh at this after the above posts...

Re: Move construction from !is(T == typeof(this))

[Stanislav Blinov via Digitalmars-d]

On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:


struct X {}

struct Y {
  this(auto ref X x)
  {
static if (__traits(isRef, x))
{
  // x is lvalue, copy construct
}
else
{
  // x MUST be rvalue(?), move construct
  // does this pattern require that I invalidate x the same 
way C++ does such that X's destructor won't clean up or crash?


"Require" is a bit too strict. But yes, if the pattern is to 
assume ownership of x's contents, then you should clear it.


Is this solid? I have a vague memory of thinking on this once 
and realising there was some edge case where it was logically 
flawed, but I can't remember clearly.


Assuming this does work, the next issue is something that 
mirrors std::move(), is there already such a thing?


We can't truly override move semantics in D. The language went 
"all in" and left little leeway to us users in that regard. 
Interestingly enough, we *can* come close in cases such as the 
code below.



struct X {}

struct Y {
  this(ref const X x)
  {
// x is lvalue reference, copy construct
  }
  this(X x)
  {
// x is an lvalue... which may be a copy of another lvalue. 
can't move

construct :/


Why not? The first overload will be called with an lvalue, i.e:

X x;
Y y1 = x;

The second one will be called in all other cases:

Y y2 = X();
Y y3 = move(x); // move(x) returns X

For second overload, x will be destructed once the ctor returns. 
I don't see any reason why you wouldn't move it's guts out.


I guess the question in this case is how overload selection may 
or may not work...
I didn't test this, but I expect it's an ambiguous call given 
an lvalue?


There is no ambiguity there as far as I can tell.
Same goes for opAssign, you can have

ref opAssign(ref X x) { /*...*/ } // assign lvalue
ref opAssign(X x) { /*...*/ } assign rvalue

I guess you mean that you don't have source for X. But in that 
case, you won't be able to "move-construct" Y from X in C++ 
either. Nor would the compiler. If you at least know the exact 
memory layout of X, you could hack together a custom move:


this(X x)
{
auto px = cast(XLayout*)cast(void*)
// move from px...
}

...but that's neither here nor there. The words "dangerous", 
"non-portable" and UB march with pitchforks right behind that 
pattern ;)

Re: Move construction from !is(T == typeof(this))

[via Digitalmars-d]

On Monday, 24 April 2017 at 14:00:33 UTC, Steven Schveighoffer 
wrote:

On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:

I wonder if this overload set could be made to work such that 
it is
certain that the non-ref overload is only called with rvalues; 
ie, given
this ambiguous call, ref is preferred for lvalues. rval can 
not call

ref, therefore must resolve to byval.


AFAIK, if you have an overload that varies solely on ref, then 
rvalues go to the non-ref and lvalues go to the ref. If this is 
not the case, it's *intended* to be the case, and should be 
filed as a bug.


auto ref just templates that. And in your case, it's actually 
clearer and cleaner not to use auto ref.


Not sure if this answers your question, or if it turns out to 
be a viable solution.


-Steve


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

[Issue 17346] New: Inconsistent l/rvalue overload resolution

[via Digitalmars-d-bugs]

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

  Issue ID: 17346
   Summary: Inconsistent l/rvalue overload resolution
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

As Steven mentioned in this forum post [1], given an overload that varies
solely on ref, then rvalue arguments should go to the non-ref and lvalue
arguments should go to the ref. A simple test indicates that the above rule is
true, but only if the ref overload is non-const:

struct X { int x; }

struct Y1
{
this(X x)
{
writeln("rvalue: ", x.x);
}

this(const ref X x) // const
{
writeln("const lvalue ref: ", x.x);
}
}

struct Y2
{
this(X x)
{
writeln("rvalue: ", x.x);
}

this(ref X x) // non-const
{
writeln("lvalue ref: ", x.x);
}
}

import std.stdio;

void main()
{
auto y1_rval = Y1(X(1));
auto x1_lval = X(2);
auto y1_lval = Y1(x1_lval); // should call the ref-overload

auto y2_rval = Y2(X(3));
auto x2_lval = X(4);
auto y2_lval = Y2(x2_lval); // should call the ref-overload
}

Expected output:
Rvalue: 1
const lvalue ref: 2
Rvalue: 3
Lvalue ref: 4

Actual output:
Rvalue: 1
Rvalue: 2
Rvalue: 3
Lvalue ref: 4

[1]: http://forum.dlang.org/post/odl0e1$1qkq$1...@digitalmars.com

--

Re: Move construction from !is(T == typeof(this))

[Steven Schveighoffer via Digitalmars-d]

On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote:


I wonder if this overload set could be made to work such that it is
certain that the non-ref overload is only called with rvalues; ie, given
this ambiguous call, ref is preferred for lvalues. rval can not call
ref, therefore must resolve to byval.


AFAIK, if you have an overload that varies solely on ref, then rvalues 
go to the non-ref and lvalues go to the ref. If this is not the case, 
it's *intended* to be the case, and should be filed as a bug.


auto ref just templates that. And in your case, it's actually clearer 
and cleaner not to use auto ref.


Not sure if this answers your question, or if it turns out to be a 
viable solution.


-Steve

Re: Move construction from !is(T == typeof(this))

[Manu via Digitalmars-d]

On 24 April 2017 at 18:36, Ola Fosheim Grøstad via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:
>
>> Now, I'm not saying that rval references are the only solution here, just
>> that I can overload the construction from an X for the rvalue and
>> non-rvalue case, which is what I want...
>>
>
> What I've done in the past is simply to create a movable_ref pointer-type.
> AFAICT that would be similar to C++ "&&" except it isn't downgraded when
> used as a parameter (which is a language feature). C++ provide that
> downgrading so that programmers don't accidentally forward a reference as a
> movable reference without making it explicit.
>

I've done that too, but that's a seriously shit solution.
You didn't comment on any of my actual questions ;)

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

[Jonathan Marler via Digitalmars-d]

On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote:

Hi Guys,

I just begun work on the x86 jit backend.

Because right now I am at a stage where further design 
decisions need to be made and those decisions need to be 
informed by how a _fast_ jit-compatible x86-codegen is 
structured.


Since I do believe that this is an interesting topic;
I will give you the over-the-shoulder perspective on this.

At the time of posting the video is still uploading, but you 
should be able to see it soon.


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

Cheers,
Stefan


Have you considered using the LLVM jit compiler for CTFE? We 
already have an LLVM front end. This would mean that CTFE would 
depend on LLVM, which is a large dependency, but it would create 
very fast, optimized code for CTFE on any platform.


Keep in mind that I'm not as familiar with the technical details 
of CTFE so you may see alot of negative ramifications that I'm 
not aware of. I just want to make sure it's being considered and 
what yours and others thoughts were.

Re: The app hanging after reach 1750MB of RAM

[Suliman via Digitalmars-d-learn]

The problem is solved. See for more detail 
https://github.com/mysql-d/mysql-native/issues/104

Re: Why need dep 32 bit library?!

[Basile B. via Digitalmars-d]

On Monday, 24 April 2017 at 12:13:41 UTC, Basile B. wrote:

On Monday, 24 April 2017 at 11:40:04 UTC, Brian wrote:

[...]


Does DMD works with  -ivh --force ?


Sorry I meant: if you install with these options.

Re: Why need dep 32 bit library?!

[Basile B. via Digitalmars-d]

On Monday, 24 April 2017 at 11:40:04 UTC, Brian wrote:

OH ... NO ...

I want install dmd to my fedora 26, but I get 64bit dmd's rpm 
package notic info:


[root@fedora Downloads]# rpm -ivh 
dmd-2.074.0-0.fedora.x86_64.rpm

error: Failed dependencies:
glibc-devel(x86-32) is needed by dmd-2.074.0-0.x86_64
libcurl(x86-32) is needed by dmd-2.074.0-0.x86_64
libgcc(x86-32) is needed by dmd-2.074.0-0.x86_64
[root@fedora Downloads]# dnf install glibc-devel libcurl libgcc
Last metadata expiration check: 2:06:24 ago on Mon Apr 24 
17:30:50 2017 CST.
Package glibc-devel-2.25-4.fc26.x86_64 is already installed, 
skipping.
Package libcurl-7.53.1-6.fc26.x86_64 is already installed, 
skipping.
Package libgcc-7.0.1-0.12.fc26.x86_64 is already installed, 
skipping.

Dependencies resolved.
Nothing to do.
Complete!


Does DMD works with  -ivh --force ?

Re: Why need dep 32 bit library?!

[Brian via Digitalmars-d]

Install very large deps 32bit libs .

[root@fedora Downloads]# dnf install glibc-devel.i686 
libcurl.i686 libgcc.i686
Last metadata expiration check: 2:16:19 ago on Mon Apr 24 
17:30:50 2017 CST.

Dependencies resolved.

 PackageArch Version  Repository  
 Size


Installing:
 glibc-develi686 2.25-4.fc26  fedora  
964 k
 libcurli686 7.53.1-6.fc26
updates-testing 288 k
 libgcc i686 7.0.1-0.12.fc26  
updates-testing  87 k

Installing dependencies:
 cyrus-sasl-lib i686 2.1.26-32.fc26   
updates-testing 164 k
 glibc  i686 2.25-4.fc26  fedora  
4.1 M
 keyutils-libs  i686 1.5.10-1.fc26
updates-testing  31 k
 krb5-libs  i686 1.15.1-7.fc26
updates-testing 793 k
 libcom_err i686 1.43.4-2.fc26fedora  
 45 k
 libcrypt-nss   i686 2.25-4.fc26  fedora  
 51 k
 libdb  i686 5.3.28-17.fc26   fedora  
801 k
 libidn2i686 2.0.0-1.fc26 
updates-testing  95 k
 libnghttp2 i686 1.21.1-1.fc26
updates-testing  76 k
 libpsl i686 0.17.0-2.fc26fedora  
 48 k
 libselinux i686 2.6-5.fc26   
updates-testing 174 k
 libsepol   i686 2.6-1.fc26   fedora  
308 k
 libssh2i686 1.8.0-2.fc26 fedora  
100 k
 libunistring   i686 0.9.7-1.fc26 fedora  
416 k
 libverto   i686 0.2.6-7.fc26 fedora  
 21 k
 nspr   i686 4.13.1-2.fc26fedora  
143 k
 nssi686 3.29.3-1.3.fc26  
updates-testing 895 k
 nss-pemi686 1.0.3-3.fc26 
updates-testing  79 k
 nss-softokni686 3.29.5-1.0.fc26  
updates-testing 411 k
 nss-softokn-freebl i686 3.29.5-1.0.fc26  
updates-testing 220 k
 nss-util   i686 3.29.5-1.0.fc26  
updates-testing  85 k
 openldap   i686 2.4.44-10.fc26   
updates-testing 362 k
 openssl-libs   i686 1:1.1.0e-1.fc26  fedora  
1.2 M
 pcre   i686 8.40-6.fc26  fedora  
203 k
 sqlite-libsi686 3.18.0-1.fc26
updates-testing 490 k
 zlib   i686 1.2.11-2.fc26fedora  
101 k


Transaction Summary

Install  29 Packages

Total download size: 13 M
Installed size: 34 M
Is this ok [y/N]: y
Downloading Packages:
(1/29): libcurl-7.53.1-6.fc26.i686.rpm  317 kB/s | 288 kB 
00:00
(2/29): libcom_err-1.43.4-2.fc26.i686.rpm48 kB/s |  45 kB 
00:00
(3/29): libpsl-0.17.0-2.fc26.i686.rpm   140 kB/s |  48 kB 
00:00
(4/29): libssh2-1.8.0-2.fc26.i686.rpm43 kB/s | 100 kB 
00:02
(5/29): glibc-devel-2.25-4.fc26.i686.rpm202 kB/s | 964 kB 
00:04
(6/29): nspr-4.13.1-2.fc26.i686.rpm 198 kB/s | 143 kB 
00:00
(7/29): zlib-1.2.11-2.fc26.i686.rpm 128 kB/s | 101 kB 
00:00
(8/29): libunistring-0.9.7-1.fc26.i686.rpm  184 kB/s | 416 kB 
00:02
(9/29): libgcc-7.0.1-0.12.fc26.i686.rpm 161 kB/s |  87 kB 
00:00
(10/29): libcrypt-nss-2.25-4.fc26.i686.rpm   54 kB/s |  51 kB 
00:00
(11/29): libidn2-2.0.0-1.fc26.i686.rpm  135 kB/s |  95 kB 
00:00
(12/29): nss-softokn-freebl-3.29.5-1.0.fc26.i68 139 kB/s | 220 kB 
00:01
(13/29): openssl-libs-1.1.0e-1.fc26.i686.rpm217 kB/s | 1.2 MB 
00:05
(14/29): libverto-0.2.6-7.fc26.i686.rpm 162 kB/s |  21 kB 
00:00
(15/29): libnghttp2-1.21.1-1.fc26.i686.rpm   93 kB/s |  76 kB 
00:00
(16/29): krb5-libs-1.15.1-7.fc26.i686.rpm   285 kB/s | 793 kB 
00:02
(17/29): nss-pem-1.0.3-3.fc26.i686.rpm   55 kB/s |  79 kB 
00:01
(18/29): glibc-2.25-4.fc26.i686.rpm 260 kB/s | 4.1 MB 
00:16
(19/29): nss-util-3.29.5-1.0.fc26.i686.rpm   82 kB/s |  85 kB 
00:01
(20/29): keyutils-libs-1.5.10-1.fc26.i686.rpm96 kB/s |  31 kB 
00:00
(21/29): libselinux-2.6-5.fc26.i686.rpm  88 kB/s | 174 kB 
00:01
(22/29): openldap-2.4.44-10.fc26.i686.rpm   126 kB/s | 362 kB 
00:02
(23/29): libsepol-2.6-1.fc26.i686.rpm   248 kB/s | 308 kB 
00:01
(24/29): pcre-8.40-6.fc26.i686.rpm  119 kB/s | 203 kB 
00:01
(25/29): nss-3.29.3-1.3.fc26.i686.rpm   101 kB/s | 

Why need dep 32 bit library?!

[Brian via Digitalmars-d]

OH ... NO ...

I want install dmd to my fedora 26, but I get 64bit dmd's rpm 
package notic info:


[root@fedora Downloads]# rpm -ivh dmd-2.074.0-0.fedora.x86_64.rpm
error: Failed dependencies:
glibc-devel(x86-32) is needed by dmd-2.074.0-0.x86_64
libcurl(x86-32) is needed by dmd-2.074.0-0.x86_64
libgcc(x86-32) is needed by dmd-2.074.0-0.x86_64
[root@fedora Downloads]# dnf install glibc-devel libcurl libgcc
Last metadata expiration check: 2:06:24 ago on Mon Apr 24 
17:30:50 2017 CST.
Package glibc-devel-2.25-4.fc26.x86_64 is already installed, 
skipping.
Package libcurl-7.53.1-6.fc26.x86_64 is already installed, 
skipping.
Package libgcc-7.0.1-0.12.fc26.x86_64 is already installed, 
skipping.

Dependencies resolved.
Nothing to do.
Complete!

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote:
The trouble is, one cannot look at a piece of code and tell if 
it follows the rules or not.


I.e. it's not about it being possible to write memory safe code 
in C or C++ (it is), it's about verifying an arbitrary piece of 
code as being memory safe.


I don't think D and Rust fare any better than modern C++ as far 
as ARBITRARY code goes. Swift and Java does...

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 22 April 2017 at 14:29:22 UTC, Stefan Koch wrote:
And for that reason I am looking to extend the interface to 
support for example scaled loads and the like.
Otherwise you and up with 1000 temporaries that add offsets to 
pointers.


What are scaled loads?

Also and perhaps more importantly I am sick and tired of 
hearing "why don't you use ldc/llvm?" all the time...


Yes, that's not fair.

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Chris via Digitalmars-d]

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote:

Hi list,

I hope the question is self-evident from the message subject. 
If not, it means: what are D developers generally called (to 
indicate that they develop in D)? The question occurred to me 
somehow while browsing some D posts on the forums just now.


DLanger? DLangist? D'er? Doer? :)

I tend to favor DLanger, FWIW.



You do know what "langer" means in County Cork, Ireland? ;) [1]

[1] https://en.wiktionary.org/wiki/langer#Noun

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Dominikus Dittes Scherkl via Digitalmars-d]

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote:

Hi list,

I hope the question is self-evident from the message subject. 
If not, it means: what are D developers generally called (to 
indicate that they develop in D)? The question occurred to me 
somehow while browsing some D posts on the forums just now.


DLanger? DLangist? D'er? Doer? :)


I would prefer D'veloper.

Re: Compare boost::hana to D

[Adrian Matoga via Digitalmars-d]

On Saturday, 22 April 2017 at 07:53:49 UTC, Johannes Pfau wrote:


OT but is there any benefit to identify events with strings? As 
long as you use compile time only events I'd prefer a syntax as 
in https://github.com/WebFreak001/EventSystem


(one benefit is that it's 100% IDE autocomplete compatible)

I guess if you want runtime registration of events identifying 
by name is useful. But then you also somehow have to encode the 
parameter types to make the whole thing safe...


I agree. Personally, I'd probably also start with something like 
WebFreak001's ES and only think about how to add run-time 
dispatch later if I absolutely need it.

Re: Compile time foreach with switch

[Nick Treleaven via Digitalmars-d-learn]

On Saturday, 22 April 2017 at 11:56:31 UTC, Nick Treleaven wrote:

If I compile the above I get:
Deprecation: switch case fallthrough - use 'goto default;' if 
intended


IMO the compiler should issue this warning with the OP's code.


https://issues.dlang.org/show_bug.cgi?id=7390#c4

[Issue 7390] Problem in generating switch cases with a static foreach

[via Digitalmars-d-bugs]

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #4 from Nick Treleaven  ---
(In reply to bearophile_hugs from comment #0)
> switch (c) { // OK
> foreach (X; xy) {
> case X: break;
> }
> default: break;
> }

The foreach break line above should error, this seems to be the bug. Still
present with 2.074.

> switch (c) {
> case 'z': break;
> foreach (X; xy) {
> case X: break;
> }
> default: break; // Error: switch case fallthrough
> }
> }

This is correct.

--

Re: Move construction from !is(T == typeof(this))

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote:
Now, I'm not saying that rval references are the only solution 
here, just that I can overload the construction from an X for 
the rvalue and non-rvalue case, which is what I want...


What I've done in the past is simply to create a movable_ref 
pointer-type. AFAICT that would be similar to C++ "&&" except it 
isn't downgraded when used as a parameter (which is a language 
feature). C++ provide that downgrading so that programmers don't 
accidentally forward a reference as a movable reference without 
making it explicit.

Re: Move construction from !is(T == typeof(this))

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 24 April 2017 at 05:00:13 UTC, rikki cattermole wrote:

There is[0] but idk how close it is to std:move and the likes.

[0] http://dlang.org/phobos/std_algorithm_mutation.html#.move


std::move doesn't do anything, it is just a type-cast.

Re: Move construction from !is(T == typeof(this))

[Manu via Digitalmars-d]

Yeah, that's not the same thing at all.

On 24 April 2017 at 15:00, rikki cattermole via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> There is[0] but idk how close it is to std:move and the likes.
>
> [0] http://dlang.org/phobos/std_algorithm_mutation.html#.move
>

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

[Joakim via Digitalmars-d]

On Saturday, 22 April 2017 at 17:17:46 UTC, Vasudev Ram wrote:

On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote:
On Fri, 2017-04-21 at 17:20 +, Vasudev Ram via 
Digitalmars-d wrote:

Hi list,

I hope the question is self-evident from the message subject. 
If not, it means: what are D developers generally called (to 
indicate that they develop in D)? The question occurred to me 
somehow while browsing some D posts on the forums just now.


DLanger? DLangist? D'er? Doer? :)

I tend to favor DLanger, FWIW.


I would hope none of these, but as ketmar said "programmer".


There is none, probably just D programmer.  Maybe the D community 
isn't big enough yet.


Terms such as Pythonista, Rubyist, Rustacean, Gopher, etc. are 
terms of tribalism and exclusion. They are attempts to ensure 
people claiming membership of the tribe reject being polyglot 
by pressuring them to eschew all other languages.


I think you are over-generalizing, and don't fully agree. 
Definitely, some people may use those terms in that manner and 
for that reason. Boo to them :)


By definition, you are creating such a term to include some 
people and exclude others.  Often it creates tribes full of 
groupthink, like Russel says, but it doesn't have to, like you 
say.


I'm never in favor of such pressuring, exclusion or whatever. 
And BTW I know what I am talking about, having seen some of it 
in real life, one example being in the Ruby world. I did Ruby 
commercially for a while, learned it even before Rails was 
created or became popular. And I frequented the Ruby message 
boards and blogs for a while, and participated in them. Saw a 
lot of what you describe, others have written about it too. A 
good amount ofjuvenile and one-up-manship behavior. That is one 
reason why I moved to Python (apart from liking it after using 
it some). The community tended to me more mature and 
engineering-oriented, rather than like the Ruby people, many of 
whom were hackish and gloated over having done some cool stuff 
with Ruby "magic" or monkey-patching (which often results in 
hard-to-find bugs - cool for experimenting, bad for production 
use). As far as being polyglot is concerned, I'm quite in favor 
of that too, and would never dream of even suggesting, let 
alone pressuring, people to "eschew all other languages", as 
you put it (this is the point about which I don't agree and 
think you are over-generalizing). In fact, I do training too, 
and once, a student who was taking a Python course from me, was 
talking about his goals (he works in another field and is 
trying to get into development). As part of that, he mentioned 
wanting "to become a good programmer (Python)" - at which point 
I immediately replied to him, that his goal should not be to 
become a good _Python_ programmer, per se, but to become a good 
_programmer_, period, because there is much more to programming 
than one or even many languages - databases, use of libraries, 
software design, testing, debugging, use of source control and 
other tools, naming conventions, other programming conventions 
and style, etc.  Mentioned books like Code Complete to him - as 
a great resource on those lines.


And I'm a polyglot programmer myself, having worked on BASIC 
(learnt on home computers), Pascal, C, Java, Informix 4GL. Done 
real commercial work in all of those, apart from the same in 
both Ruby and Python. And even keep dabbling in new languages 
now and then. That's how I came across D, for example, which I 
like a lot - IIRC it was by reading some article in a computer 
magazine, could have been Dr. Dobbs.


A good programmer can work professionally with a number of 
languages, the psychology of programming people have data 
supporting this theory – if the languages have different 
computational models.


Totally agreed.

Thus I would claim to be a programmer currently working with D 
for the project I am working on just now, with SCons/Python 
for the build system. In a while it will be C++ on another 
project with CMake. Later still it will be C and Meson on a 
different project. Further on it will be Kotlin and Frege 
using Gradle for yet another project.


Same here. Language agnostic. It's the best way. Another 
anecdote - once, in a company where I worked and was managing a 
product team, I had a need to write a small reminder utility 
for my own use. The project was in C++ and Java (I worked on 
the Java side), but since I knew Python and it was a good fit 
for the tool, I did it in Python - in a few minutes. One of my 
team members wanted to do it too, so, since he only knew Java, 
when I told him I was doing it in Python and it would be done 
very fast, he smiled and said "I'll do it in Java" - and 
proceeded take more time than I did for the same functionality. 
Nor was there any performance or other requirement that 
necessitated Java - he did it because it was the only language 
he knew. "Use the right tool for the job" and all that ...


You're 

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

[Walter Bright via Digitalmars-d-announce]

On 4/23/2017 5:04 AM, Guillaume Piolat wrote:

The rules of leak-free, exception-safe C++11 aren't so hard.
- single-owneship for everything, invent fake owner if needed
- std::unique_ptr for owning pointer, raw pointers for borrowed
  (unique_ptr neatly avoids to write a RAII wrapper for everything)

When teams internalize these rules, no more leaks, no more double-free, etc.
Hence Rust that sanctified this style.


The trouble is, one cannot look at a piece of code and tell if it follows the 
rules or not.


I.e. it's not about it being possible to write memory safe code in C or C++ (it 
is), it's about verifying an arbitrary piece of code as being memory safe.

mir.array.primitives and mir.bitmanip were added

[9il via Digitalmars-d-announce]

Mir release v0.4.12 comes with simple but powerful API additions.

mir.array.primitives [1]
===
Added empty, front, back pop*[N/Exactly], length primitives.

Difference with Phobos:

1. Do not break LDC fastmath optimisations. (because they marked 
@fastmath) This is important for sci and numeric code.


2. Strings are just common arrays without decoding. 
std.uni.byCodePoint should be used explicitly to operate strings 
as ranges of chars.


3. Has ndslice-like API, e.g. `auto l = arr.length!0;` and `auto 
x = arr.front!0`. This is useful for generic multidimensional 
code that should work with arrays as with 1-dimensional ndslices.


mir.bitmanip [2]
===

Contains modified bitfields, taggedClassRef, taggedPointer from 
std.bitmanip. Authors are Walter Bright, Andrei Alexandrescu, 
Amaury SECHET. Ping me please if I missed someone.


Difference with Phobos:

1. Generated mixins are templates. This awesome for writing 
source libraries and betterC code. For examples size of Mir CPUID 
compiled in betterC mode was reduced few times after migration to 
mir.


[1] 
http://docs.algorithm.dlang.io/latest/mir_array_primitives.html

[2] http://docs.algorithm.dlang.io/latest/mir_bitmanip.html

Best reagards,
Ilya