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

[Manu via Digitalmars-d]

On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d
 wrote:
> On 01.04.2018 19:20, Andrei Alexandrescu wrote:
>>
>> On 3/28/18 7:50 AM, Timon Gehr wrote:
>>>
>>> "The proposal could be amended to accept mutable ref's depending on the
>>> value-judgement balancing these 2 use cases. Sticking with const requires no
>>> such value judgement to be made at this time, and it's much easier to relax
>>> the spec in the future with emergence of evidence to do so."
>>>
>>> Just get it right the first time. "const" is a serious API restriction,
>>> and it shouldn't be forced on anyone, even intermittently until they figure
>>> out that it is too restrictive (as well as viral).
>>
>>
>> A great way to move things forward here, Timon, is to write a pull request
>> against the DIP with motivating text and examples.
>
>
> I agree, but unfortunately I have many other things on my plate right now.
> Add to this that there are six or seven other DIPs that I really ought to
> finish/write/implement/rebase. I'll try to get back to this soon. Here, I
> was trying to make sure that popular misconceptions do not gain more
> traction.

I'm convinced. There are lots of reasons it should not only apply to const.
I only originally went that way because it was more conservative,
easier to relax, and because the stated reason why you can't _already_
do this thing is allegedly because people freak out at the idea that a
function might return data into a temporary. 'const' prevents that
from being a possibility, but unlike C++, there are significant useful
cases for not restricting to const.
The most exciting for me is pipeline programming (ie, UFCS chains),
which are a major winning feature of D. They'll be more convenient
among other things.

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

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

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

Seb  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All
   Severity|enhancement |major

--

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
https://github.com/dlang/dlang.org/pull/2323

--

[Issue 18703] Ddoc Backticks inside macro dont work.

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Seb  ---
Yeah this should really work..
If you depend on this - `$(D_INLINECODE` might be a workaround:

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

or:

Macros:
  D = $1

--

Re: DIP Draft Review: ref const(T) should receive r-values

[Mike Parker via Digitalmars-d-announce]

On Monday, 2 April 2018 at 05:09:29 UTC, Mike Parker wrote:

On Monday, 2 April 2018 at 05:06:21 UTC, Mike Parker wrote:


Please keep feedback on the DIP in the PR thread.

Thanks in advance to all who participate.


https://github.com/dlang/DIPs/pull/109


Sorry everyone. Got my links mixed up. This is the rvalue 
references DIP:


https://github.com/dlang/DIPs/pull/111

Re: DIP Draft Review: Hooking D's struct move semantics

[Mike Parker via Digitalmars-d-announce]

On Monday, 2 April 2018 at 05:07:25 UTC, Mike Parker wrote:

On Monday, 2 April 2018 at 04:34:03 UTC, Mike Parker wrote:



Please keep feedback on the DIP in the PR thread.

Thanks in advance to all who participate.


https://github.com/dlang/DIPs/pull/111


Sorry everyone. Got my links mixed up. This is the opMove DIP:

https://github.com/dlang/DIPs/pull/109

DIP Draft Review: ref const(T) should receive r-values

[Mike Parker via Digitalmars-d-announce]

This DIP is a candidate to become DIP 1014. There's already been 
some discussion about this in the forums and some feedback on the 
PR, but more Draft Review feedback is needed.


The intent of the Draft Review is primarily to find obvious flaws 
with the DIP, e.g. structural faults, uncovered bases, lack of 
clarity, etc.. At this stage of the process, the end goal is to 
shape the DIP into a strong draft for in-depth review. Feedback 
at this stage will not be included in the review summary, so any 
theoretical discussions or in-depth examination of minutiae are 
best saved for the community review.


Please keep feedback on the DIP in the PR thread.

Thanks in advance to all who participate.

Re: Optional parameters?

[Norm via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 
wrote:
I currently have a situation where I want to have a function 
that accepts a parameter optionally.


I thought maybe Nullable!int might work:

void foo(Nullable!int) {}

void main()
{
   foo(1); // error
   int x;
   foo(x); // error
}

Apparently, I have to manually wrap an int to get it to pass. 
In other languages that support optional types, I can do such 
things, and it works without issues.


I know I can do things like this:

void foo(int x) { return foo(nullable(x)); }

But I'd rather avoid such things if possible. Is there a way 
around this? Seems rather limiting that I can do:


Nullable!int x = 1;

but I can't implicitly convert 1 to a Nullable!int for function 
calls.


-Steve


I don't know if this helps but when I hit this situation I 
usually resort to templates, e.g.


---
void foo(T)(T val = Nullable!int()) if(is(T : int) || is(T == 
Nullable!int))

{
  writeln(val);
}

void main()
{
   foo(1); // prints: 1
   int x;
   foo(x); // prints: 0
   auto val = Nullable!int(5);
   foo(val); // prints: 5
   foo(); // prints: Nullable.null
}
---

Cheers,
Norm

DIP Draft Review: Hooking D's struct move semantics

[Mike Parker via Digitalmars-d-announce]

This DIP is a candidate to become DIP 1014. There has been light 
feedback already, but there's room for more. Everyone is invited 
to participate.


The intent of the Draft Review is primarily to find obvious flaws 
with DIP, e.g. structural faults, uncovered bases, lack of 
clarity, etc.. At this stage of the process, the end goal is to 
shape the DIP into a strong draft for in-depth review. Feedback 
at this stage will not be included in the review summary, so any 
theoretical discussions or in-depth examination of minutiae are 
best saved for the community review.


Please keep feedback on the DIP in the PR thread.

Thanks in advance to all who participate.

[Issue 18703] New: Ddoc Backticks inside macro dont work.

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

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

  Issue ID: 18703
   Summary: Ddoc Backticks inside macro dont work.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: var.spool.mail...@gmail.com

$(TEST)

MACROS:
TEST = `this should be highlighted as code`

generates:

`this should be highlighted as code`

but should generate:

this should be highlighted as code

--

[Issue 17607] not an associative array initializer

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
FYI: while it doesn't fix this bug, this PR is still very related this this
enhancement request:

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

--

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

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

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

jonath...@gmail.com changed:

   What|Removed |Added

URL||https://dlang.org/articles/
   ||comparison.html

--

[Issue 18702] New: FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

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

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

  Issue ID: 18702
   Summary: FAQ item "What does D have that C++ doesn't?"
comparison link
(https://dlang.org/articles/comparison.html) returns
404
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: jonath...@gmail.com

--

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Monday, April 02, 2018 00:25:52 Nicholas Wilson via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 17:08:37 UTC, Andrei Alexandrescu
> wrote:
> > On 4/1/18 10:59 AM, Nicholas Wilson wrote:
> > [...]
> > int[] sneaky;
> > struct A
> > {
> >
> > private int[] innocent;
> > this(this)
> > {
> >
> > sneaky = innocent;
> >
> > }
> >
> > }
> > void main()
> > {
> >
> > immutable a = A([1, 2, 3]);
> > auto b = a;
> > sneaky[1] = 42; // oops
> > import std.stdio;
> > writeln(a.innocent); // ops
> >
> > }
> >
> > Sadly this (and many similar ones) compiles and runs
> > warning-free on today's compiler. We really need to close this
> > loop, like, five years ago.
>
> How much of this class of bug would be eliminated by requiring
> that `this(this)` be pure for assignment to const and immutable
> objects? Arguably this(this) should always be pure in any sane
> program. The only reason I can think of is if you're trying to
> perf the number of copies you're making, but there is compiler
> help for that.

All kinds of things could be done with a postlbit costructor that don't
actually involve copying. These include logging or printing something, and
they could include stuff like reference counting, which may or may not need
access to something external. debug statements would solve some uses cases
but not all. Requiring that this(this) be pure has some of the same issues
that requiring opEquals to be pure or const or whatever has. It makes sense
in _most_ cases, but occasionally, there are good reasons for it not to be -
especially in a systems language.

We have to be _very_ careful about requiring any particular attribute much
of anywhere. Doing so typically causes problems - e.g. those we have with
Object's opEquals, opCmp, toHash, and toString. That decision really needs
to be left up to a particular code base. It's also a big part of why
templates infer attributes. Someone can write their code in such a way that
their code base requires a particular attribute, but in general, language
features shouldn't be requiring any specific attributes, or we'll just be
backing ourselves into another corner.

- Jonathan M Davis

Re: Deprecating this(this)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 1 April 2018 at 17:08:37 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 10:59 AM, Nicholas Wilson wrote:

for 1. consider
immutable foo = ...;
immutable bar = foo;
to be
immutable foo = ...;
immutable bar = () {mutable _ = bitcopy(foo); _.__postblit(); 
return _;}();


Negative. The problem is typechecking postblit itself, not its 
invocation.


Nit sure that I follow but, see comment below on your immutable 
example.


for 2. you would have to synchronize anyway for shared, it 
makes no difference.


Negative. Consider:

shared struct Point
{
private long x, y, z;
private Mutex mutex;
...
}

Task: define the copy primitive of Point so atomically copy x, 
y, and z using mutex. The problem is, the compiler will memcpy 
the three longs non-atomically before the user even gets a 
crack at intercepting the operation.




What I meant was:
Point p = ...;
auto pp = p; // bit copy + postblit = WRONG
Point pp;
synchronized (p.mutex) { pp = p; } // synchronised: bitcopy is 
inseparable from the postblit


Perhaps there is a way to make that automatic / nicer to use?


[...]
int[] sneaky;
struct A
{
private int[] innocent;
this(this)
{
sneaky = innocent;
}
}
void main()
{
immutable a = A([1, 2, 3]);
auto b = a;
sneaky[1] = 42; // oops
import std.stdio;
writeln(a.innocent); // ops
}

Sadly this (and many similar ones) compiles and runs 
warning-free on today's compiler. We really need to close this 
loop, like, five years ago.


How much of this class of bug would be eliminated by requiring 
that `this(this)` be pure for assignment to const and immutable 
objects? Arguably this(this) should always be pure in any sane 
program. The only reason I can think of is if you're trying to 
perf the number of copies you're making, but there is compiler 
help for that.

Re: Optional parameters?

[Ali via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 
wrote:
I currently have a situation where I want to have a function 
that accepts a parameter optionally.


why not simply use function overloading?

Re: Optional parameters?

[Boris-Barboris via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 22:44:45 UTC, Jonathan M Davis wrote:
Which doesn't work in @safe code and doesn't work when you have 
an rvalue as you would when passing 42. Ultimately, using 
pointers ultimately either requires explicitly allocating stuff 
on the heap to be able to pass rvalues, or it has the same 
restrictions that ref does in terms of passing rvalues. You can 
certainly take that approach if you'd like, but overall, I 
think that it's safe to say that using Nullable generally 
causes fewer problems.


1). There's nothing wrong with @trusted.
2). Rvalue it trivially converted to lvalue on the stack using 
local variable.
3). You haven't shown syntax for passing null. Pointer is 
foo(null). Yours will probably be foo(nullable!int());
4). I certanly wouldn't like typing nullable(...) for each 
optional parameter, I see it as a much bigger problem.

Re: Optional parameters?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, April 01, 2018 22:34:16 Seb via Digitalmars-d-learn wrote:
> On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer
>
> wrote:
> > I currently have a situation where I want to have a function
> > that accepts a parameter optionally.
> >
> > I thought maybe Nullable!int might work:
> >
> > void foo(Nullable!int) {}
> >
> > void main()
> > {
> >
> >foo(1); // error
> >int x;
> >foo(x); // error
> >
> > }
> >
> > Apparently, I have to manually wrap an int to get it to pass.
> > In other languages that support optional types, I can do such
> > things, and it works without issues.
> >
> > I know I can do things like this:
> >
> > void foo(int x) { return foo(nullable(x)); }
> >
> > But I'd rather avoid such things if possible. Is there a way
> > around this? Seems rather limiting that I can do:
> >
> > Nullable!int x = 1;
> >
> > but I can't implicitly convert 1 to a Nullable!int for function
> > calls.
> >
> > -Steve
>
> My workaround is to use struct initialization:
>
> ---
> import std.stdio, std.typecons;
>
> static struct FooConfig
> {
>  Nullable!int a;
> }
>
> void foo(FooConfig optionalConfig = FooConfig.init)
> {
>  optionalConfig.writeln;
> }
>
> void main()
> {
>  foo();
>
>  FooConfig params = {
> a: 42,
>  };
>  foo(params);
>  //foo(FooConfig(42)); // <- hehe, no implicit conversion
> }
> ---
>
> https://run.dlang.io/is/HvN701
>
> I know the separate line and variable is annoying.
> With the in-place struct-initialization DIP
> (https://github.com/dlang/DIPs/pull/71), it would become sth.
> like:
>
> foo(FooConfig({a : 42}));
> foo(FooConfig{a : 42});
>
> (syntax is not clear yet and I still haven't gotten around
> implementing this in DMD)

How is any of that better than just using nullable(42)? The whole annoyance
here is that there is no implicit conversion and that something explicit is
required. Changing what the explicit construction is doesn't help much, from
where I sit, something like

foo(FooConfig({a : 42:}));

is way worse than

foo(nullable(42));

and even if you're sticking to FooConfig,

foo(FooConfig(42));

would be less verbose. The whole {a : 42} thing only starts making sense
when you have a struct with several members where you want to be able to
initialize only certain ones at a time without declaring all of the various
constructors to allow all of the combinations and/or you have enough members
of the same type that you pretty much need to provide the names with the
arguments for it to be clear what's being initialized. Otherwise, normal
construction works just fine, and it wouldn't help at all in a case like
Steven has where he's trying to pass a type and have it implicitly converted
to another when it's passed. If you're going to do something explicit,
nullable(value) works just fine. It's the fact that something explicit is
required at all that's the problem.

- Jonathan M Davis

So you want faster compilation with rdmd?

[Seb via Digitalmars-d]

Have you ever wondered why `pragma(msg, "foo")` is appearing 
twice when compiling something with rdmd?
Well, it's because rdmd is compiling the program twice and with 
evaluating all the Phobos template monstrosities this is easily 
~30-40% of the entire build.


There have been many attempts at fixing this and in 2.079 we 
finally got -i:


https://dlang.org/changelog/2.079.0.html#includeimports
https://github.com/dlang/dmd/pull/7099

However, all attempts of fixing this in rdmd have failed:

- https://github.com/dlang/tools/pull/191 (before -i, closed in 
favor of #194)
- https://github.com/dlang/tools/pull/194 (was reverted due to a 
regression)
- https://github.com/dlang/tools/pull/271 (was reverted to 
maintain backwards compatibility)
- https://github.com/dlang/tools/pull/292 (was closed due to too 
much resistance)


So it doesn't look like in 2.080 rdmd will take advantage of this.

Yo, no problem I can use `alias rdmd=dmd -run -i` now, right?
--

Well, not so fast `-run` has severe design defects. See 
https://github.com/dlang/dmd/pull/7927).
tl;dr: you can use `-i`, but you will need to use a custom 
wrapper like e.g. this one:


---
#!/bin/bash

DMD="${DMD:-dmd}"
file="$1"
other_flags=()
shift

for arg in "$@" ; do
if [ -f "$arg" ] ; then
other_flags+=("$file")
file="$arg"
else
other_flags+=("$arg")
fi
done

"$DMD" -i "${other_flags[@]}" -run "${file}"
---


Oh and if you don't like this wrapper, a fork of rdmd is here: 
https://github.com/marler8997/rund

Re: Optional parameters?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, April 01, 2018 22:37:17 Boris-Barboris via Digitalmars-d-learn 
wrote:
> On Sunday, 1 April 2018 at 22:25:45 UTC, Jonathan M Davis wrote:
> > How would a pointer help? Instead of doing
> >
> > foo(nullable(42))
> >
> > he'd have to do
> >
> > foo(new int(42))
> >
> > which is just one character shorter and ends up allocating on
> > the heap, unlike with Nullable.
> >
> > - Jonathan M Davis
>
> foo();

which doesn't work in @safe code and doesn't work when you have an rvalue as
you would when passing 42. Ultimately, using pointers ultimately either
requires explicitly allocating stuff on the heap to be able to pass rvalues,
or it has the same restrictions that ref does in terms of passing rvalues.
You can certainly take that approach if you'd like, but overall, I think
that it's safe to say that using Nullable generally causes fewer problems.

- Jonathan M Davis

Re: Optional parameters?

[Boris-Barboris via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 22:25:45 UTC, Jonathan M Davis wrote:


How would a pointer help? Instead of doing

foo(nullable(42))

he'd have to do

foo(new int(42))

which is just one character shorter and ends up allocating on 
the heap, unlike with Nullable.


- Jonathan M Davis



foo();

Re: Optional parameters?

[Seb via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 
wrote:
I currently have a situation where I want to have a function 
that accepts a parameter optionally.


I thought maybe Nullable!int might work:

void foo(Nullable!int) {}

void main()
{
   foo(1); // error
   int x;
   foo(x); // error
}

Apparently, I have to manually wrap an int to get it to pass. 
In other languages that support optional types, I can do such 
things, and it works without issues.


I know I can do things like this:

void foo(int x) { return foo(nullable(x)); }

But I'd rather avoid such things if possible. Is there a way 
around this? Seems rather limiting that I can do:


Nullable!int x = 1;

but I can't implicitly convert 1 to a Nullable!int for function 
calls.


-Steve


My workaround is to use struct initialization:

---
import std.stdio, std.typecons;

static struct FooConfig
{
Nullable!int a;
}

void foo(FooConfig optionalConfig = FooConfig.init)
{
optionalConfig.writeln;
}

void main()
{
foo();

FooConfig params = {
   a: 42,
};
foo(params);
//foo(FooConfig(42)); // <- hehe, no implicit conversion
}
---

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

I know the separate line and variable is annoying.
With the in-place struct-initialization DIP 
(https://github.com/dlang/DIPs/pull/71), it would become sth. 
like:


foo(FooConfig({a : 42}));
foo(FooConfig{a : 42});

(syntax is not clear yet and I still haven't gotten around 
implementing this in DMD)

Re: Optional parameters?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, April 01, 2018 22:06:57 Boris-Barboris via Digitalmars-d-learn 
wrote:
> On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer
>
> wrote:
> > I currently have a situation where I want to have a function
> > that accepts a parameter optionally.
>
> I would simply use a pointer for this. Fighting D grammar seems
> too much of a hassle for such simple task.

How would a pointer help? Instead of doing

foo(nullable(42))

he'd have to do

foo(new int(42))

which is just one character shorter and ends up allocating on the heap,
unlike with Nullable.

- Jonathan M Davis

Re: dub / libs / rebuild not triggered

[Seb via Digitalmars-d]

On Sunday, 1 April 2018 at 17:01:46 UTC, Robert M. Münch wrote:

Hi, I have the following line in my dub.json file:

"libs-windows-x86_64": ["user32", "kernel32", "gdi32", 
"b2d_playground"]


b2d_playground is a C based .lib file. If this lib is updated 
and I run: dub build --arch=x86_64 nothing happens. The EXE is 
not rebuild, taking into accoun the updated lib file. IMO dub 
should re-link the EXE.


Is this by design or a bug?


Bug. Imho dub should compare the timestamp of its dependencies 
and see whether they are newer than the target like e.g. Make.


https://github.com/dlang/dub/issues/new

Re: Optional parameters?

[Boris-Barboris via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 
wrote:
I currently have a situation where I want to have a function 
that accepts a parameter optionally.


I would simply use a pointer for this. Fighting D grammar seems 
too much of a hassle for such simple task.

Re: Optional parameters?

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, April 01, 2018 11:54:16 Steven Schveighoffer via Digitalmars-d-
learn wrote:
> I currently have a situation where I want to have a function that
> accepts a parameter optionally.
>
> I thought maybe Nullable!int might work:
>
> void foo(Nullable!int) {}
>
> void main()
> {
> foo(1); // error
> int x;
> foo(x); // error
> }
>
> Apparently, I have to manually wrap an int to get it to pass. In other
> languages that support optional types, I can do such things, and it
> works without issues.
>
> I know I can do things like this:
>
> void foo(int x) { return foo(nullable(x)); }
>
> But I'd rather avoid such things if possible. Is there a way around
> this? Seems rather limiting that I can do:
>
> Nullable!int x = 1;
>
> but I can't implicitly convert 1 to a Nullable!int for function calls.

You'll have to call nullable. D has no form of implicit construction. You
can use alias this to define how to convert _from_ a type but not _to_ a
type, and alias this is the only way to define implicit conversions in D. I
think that it works with variable initialization, because on some level, the
compiler treats

Type a = args;

the same as

auto a = Type(args);

e.g.

struct S
{
int _i;

this(int i)
{
_i = i;
}
}

void main()
{
S s = 42;
}

compiles with no alias this at all. Curiously though, if you remove the
explicit constructor, it doesn't compile, even though

auto s = S(42);

would still compile.

Another area where this behavior can be annoying is when returning from a
function call. e.g. this won't compile:

Nullable!int foo(int i)
{
if(i != 42)
return i;
return Nullable!int.init;
}

i needs to be wrapped in a call to nullable or to Nullable!int's constructor
in order for it to compile.

As I understand it, the lack of ability to define implicit construction is
part of the attempt to avoid some of the problems with regards to stuff like
function hijacking that come in C++ from allowing all of the implicit
conversions that it allows. It may also be in part to prevent issues related
to being able to define the same implicit conversion multiple ways (e.g. if
type A implictly casts to B, and you can implicitly construct B from A,
which conversion does the compiler use when converting A to B?).

Ultimately, it's a bit of a double-edged sword in that it prevents certain
classes of bugs but also makes it impossible to do something like have a
function parameter be a wrapper type while the function argument is the type
being wrapped. So, you couldn't do something like use string for IP
addresses everywhere in your code and then change it to a struct later, and
have all of the function calls that passed strings still work without
updating them (which you can do in C++).

Given how problematic implicit conversions tend to be in generic code, I
often think that we might be better off with no user-defined implicit
conversions in D at all, but Nullable is one case where the fact that we
can't define implicit construction gets annoying.

- Jonathan M Davis

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

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

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

--- Comment #15 from Manu  ---
Okay, I must have had some workaround... I don't remember what exactly, it was
some years ago. I probably wrapped it in layers until it worked.
Regardless, it should work. My colleague just tried to do this and asked me why
it didn't work...
I have no recollection of workarounds I might have used.

--

Re: __has_side_effects

[Mark via Digitalmars-d]

On Saturday, 31 March 2018 at 20:44:13 UTC, Andrei Alexandrescu 
wrote:
Yah, only strongly pure functions would qualify. Indeed that's 
easy for the compiler to figure - so I'm thinking 
pragma(isStronglyPure, expression) would be easy to define.


What would be some good uses of this?


Andrei


It can be used for some rudimentary compiler checks. Namely, in 
some contexts it doesn't make sense for an expression to have (or 
rather not have) any side effects:
- The increment section in a for loop must have a side effect, 
unless it's empty.
- An assert expression shouldn't have any side effects (because 
assertions disappear in release mode).


Maybe the compiler already does such checks, I don't know.

In general this seems far less useful than the concept of a pure 
function.

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

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #14 from Seb  ---
Here's the regression tester with all 19 versions from 2.060 to 2.079:

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

Anyhow, I think we all agree that Manu's use case should work, so let's focus
on fixing that (and avoid the off-topic discussion whether this may or may nor
have worked a long time ago).

--

Re: D compiles fast, right? Right??

[Stefan Koch via Digitalmars-d]

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote:

On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote:

Could be faster.


It's been a fair amount of time since somebody has done 
profiling of dmd. It needs to be done. There's probably plenty 
of low hanging fruit. Speculating about why it is slow is 
pointless without data.


have a look at https://github.com/dlang/dmd/pull/7792 for a 
little profiling utility which tells you about which parts of a 
programm draw compiletime.


Whenever I see long compile times 90% of it is due to templates.

Re: newCTFE Status March 2018

[Nordlöw via Digitalmars-d]

On Sunday, 1 April 2018 at 18:32:00 UTC, Stefan Koch wrote:

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

[...]


Oh I was not aware people would try this :)
I have fixed the build please pull.


Thanks!

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

[Timon Gehr via Digitalmars-d]

On 01.04.2018 19:20, Andrei Alexandrescu wrote:

On 3/28/18 7:50 AM, Timon Gehr wrote:
"The proposal could be amended to accept mutable ref's depending on 
the value-judgement balancing these 2 use cases. Sticking with const 
requires no such value judgement to be made at this time, and it's 
much easier to relax the spec in the future with emergence of evidence 
to do so."


Just get it right the first time. "const" is a serious API 
restriction, and it shouldn't be forced on anyone, even intermittently 
until they figure out that it is too restrictive (as well as viral).


A great way to move things forward here, Timon, is to write a pull 
request against the DIP with motivating text and examples.


I agree, but unfortunately I have many other things on my plate right 
now. Add to this that there are six or seven other DIPs that I really 
ought to finish/write/implement/rebase. I'll try to get back to this 
soon. Here, I was trying to make sure that popular misconceptions do not 
gain more traction.

Re: newCTFE Status March 2018

[Stefan Koch via Digitalmars-d]

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

[...]


What is going on here is that it tries to build the gccjit 
backend which is currently in a dysfunctional state.
I am currently getting trying to get libgccjit working such that 
I can make use of it's debug output, while I am trying to find 
out what is wrong with dynamic casts.

Re: newCTFE Status March 2018

[Stefan Koch via Digitalmars-d]

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

[...]


Oh I was not aware people would try this :)
I have fixed the build please pull.

Re: Optional parameters?

[Alex via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer 
wrote:

void main()
{
   foo(1); // error
   int x;
   foo(x); // error
}



For the first line, I had the same problem a while ago...
https://issues.dlang.org/show_bug.cgi?id=15792

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

[Andrei Alexandrescu via Digitalmars-d]

On 3/28/18 7:50 AM, Timon Gehr wrote:
"The proposal could be amended to accept mutable ref's depending on the 
value-judgement balancing these 2 use cases. Sticking with const 
requires no such value judgement to be made at this time, and it's much 
easier to relax the spec in the future with emergence of evidence to do 
so."


Just get it right the first time. "const" is a serious API restriction, 
and it shouldn't be forced on anyone, even intermittently until they 
figure out that it is too restrictive (as well as viral).


A great way to move things forward here, Timon, is to write a pull 
request against the DIP with motivating text and examples.

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 10:59 AM, Nicholas Wilson wrote:

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu wrote:
There's a mix of fundamental flaws and bugs. I'll get to the flaws in 
a second. About the bugs: people have altered their code in various 
ways to work with the bizarre semantics of this(this). Now, if we fix 
various bugs in this(this) by virtually redefining it, then we'll 
break a lot of code in a lot of ways. To wit, we fixed a small issue 
and it already created problems: 
https://github.com/dlang/dmd/pull/8032. That didn't contribute to the 
decision but is quite illustrative.


I found two fundamental flaws with this(this):

1. For immutable objects, typechecking in the presence of successive 
modifications of data (first assignment by the compiler, then 
modification by the user) is very difficult if not impossible. I don't 
know how to do it. The single initialization model (raw/cooked) used 
currently in regular immutable constructors works reasonably well and 
is robust.


2. For shared objects, the part done by the compiler and the part done 
by this(this) should be synchronized together. This makes it 
impossible for the user to e.g. define a struct that gets copied 
atomically.




See my other reply: but why is it necessary to consider the blit 
logically distinct from the postblit w.r.t to program flow observability?


for 1. consider
immutable foo = ...;
immutable bar = foo;
to be
immutable foo = ...;
immutable bar = () {mutable _ = bitcopy(foo); _.__postblit(); return _;}();


Negative. The problem is typechecking postblit itself, not its invocation.

for 2. you would have to synchronize anyway for shared, it makes no 
difference.


Negative. Consider:

shared struct Point
{
private long x, y, z;
private Mutex mutex;
...
}

Task: define the copy primitive of Point so atomically copy x, y, and z 
using mutex. The problem is, the compiler will memcpy the three longs 
non-atomically before the user even gets a crack at intercepting the 
operation.


There'd be an additional issue - this(this) is non-templated, which 
requires combinatorial additions when qualifiers are present on the 
source or destination side.


(Perhaps this is what you're referring to, but all you have said so far 
is "this doesn't work and we need to fix it") the post blit is surely 
like a destructor: there's only one way to do it, irrespective of the 
attributes, especially of the intermediate is considered mutable until 
the end of post blit, like static module constructors initialising 
global immutables.


Negative. Ignoring qualifiers during copying opens holes in the type 
system the size of China. Or at least Australia as it were :o). Consider:


int[] sneaky;
struct A
{
private int[] innocent;
this(this)
{
sneaky = innocent;
}
}
void main()
{
immutable a = A([1, 2, 3]);
auto b = a;
sneaky[1] = 42; // oops
import std.stdio;
writeln(a.innocent); // ops
}

Sadly this (and many similar ones) compiles and runs warning-free on 
today's compiler. We really need to close this loop, like, five years ago.


I agree that we should fix any type checking bugs that may be present, 
and that we should strive to not make the same mistake twice, however I 
wouldn't call either of the above cases a showstopper. You will need to 
show more of what is broken and why it is broken given the expected 
breakage.


Such discussions will be indeed present in the DIP.


Andrei

dub / libs / rebuild not triggered

[Robert M. Münch via Digitalmars-d]

Hi, I have the following line in my dub.json file:

"libs-windows-x86_64": ["user32", "kernel32", "gdi32", "b2d_playground"]

b2d_playground is a C based .lib file. If this lib is updated and I 
run: dub build --arch=x86_64 nothing happens. The EXE is not rebuild, 
taking into accoun the updated lib file. IMO dub should re-link the EXE.


Is this by design or a bug?

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Fast GC allocation of many small objects

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

On Sunday, 1 April 2018 at 10:59:55 UTC, Alexandru jercaianu 
wrote:

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:
On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu 
wrote:

Hello,

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

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

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


Thanks!

Is a `minAlign` of 16 recommended over 8 when allocating 
classes or arrays?

Hi,
I'm glad it was helpful.
To be honest, I don't know which alignment would be better and 
it probably depends on your machine.
This here says that 16 would work just fine [1] so I would go 
with that.


[1] - 
https://dlang.org/library/std/experimental/allocator/common/platform_alignment.html


Thanks. I presume if we know what type we should allocate, in my 
case a class `C`, we should use `C.alignof` otherwise we should 
default to `platformAlignment`.

Re: newCTFE Status March 2018

[Per Nordlöw via Digitalmars-d]

On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:

85 to 90% maybe.

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


I tried building your newCTFE_reboot branch but it fails as

expression.d(15724): Deprecation: Implicit string concatenation 
is deprecated, use "identity comparison of static arrays " ~ 
"implicitly coerces them to slices, " instead
expression.d(15725): Deprecation: Implicit string concatenation 
is deprecated, use "implicitly coerces them to slices, " ~ "which 
are compared by reference" instead
gluelayer.d(61): Deprecation: Symbol ddmd.backend.code_x86.code 
is not visible from module gluelayer because it is privately 
imported in module code
ctfe/ctfe_bc.d(4): Deprecation: Symbol ddmd.func.FuncDeclaration 
is not visible from module ctfe_bc because it is privately 
imported in module declaration
ctfe/ctfe_bc.d(4): Deprecation: Symbol ddmd.func.CtorDeclaration 
is not visible from module ctfe_bc because it is privately 
imported in module declaration

Sizeof BCValue: 56LU
ctfe/ctfe_bc.d(262): Error: module `bc_gccjit_backend` is in file 
'ddmd/ctfe/bc_gccjit_backend.d' which cannot be read

import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
posix.mak:338: receptet för målet ”dmd” misslyckades
make[1]: *** [dmd] Fel 1
make[1]: Lämnar katalogen ”/home/per/Work/dmd/src”
posix.mak:8: receptet för målet ”all” misslyckades
make: *** [all] Fel 2

I'm on Ubuntu 17.10 and building with DMD 2.079.

Global hotkey with GTK based application under Windows

[ANtlord via Digitalmars-d-learn]

Hello! I implement a GTK-D based application for Windows and 
Linux. In case of Linux there isn't any problem, I use binding[1] 
for libkeybinder. In case of Windows I can't find convinient way 
to implement global shortcuts. There is a way to get it done is 
use of WinAPI but it's not convinient by a couple of things.


WinAPI provides RegisterHotKey method[2] but I have no idea how 
to get HWND using GTK-D. If I get it done I get a problem to 
handle it. Design of WinAPI means handling of hotkey in a loop 
like so[3]. I could get the thing done using tick callback[4] but 
I use the callback for another stuff, and I don't know whether 
GTK-D supports multiple tick callbacks, I can't get it at least.


If anyone has an idea, please tell me because I ran out. Thanks 
in advance!


[1] https://github.com/dhasenan/keybinder
[2] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646309.aspx

[3] http://vpaste.net/FwhMD
[4] 
http://gtk-d.dpldocs.info/gtk.Widget.Widget.addTickCallback.1.html

Re: std.variant Is Everything Cool About D

[Meta via Digitalmars-d-announce]

On Saturday, 31 March 2018 at 17:36:30 UTC, Pjotr Prins wrote:

Great blog. Thanks.


Thank you, glad you liked it.

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 14:33:14 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 9:39 AM, Uknown wrote:
On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 2:22 AM, Uknown wrote:

[...]

Terrific, thanks!!


Created the PR: https://github.com/dlang/phobos/pull/6403

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu 
wrote:
Now, if we fix various bugs in this(this) by virtually 
redefining it, then we'll break a lot of code in a lot of ways. 
To wit, we fixed a small issue and it already created problems: 
https://github.com/dlang/dmd/pull/8032. That didn't contribute 
to the decision but is quite illustrative.


Yeah, I absolutely see value in starting fresh with different 
syntax, even if you were just implementing the same postblit idea 
again.



I found two fundamental flaws with this(this):

1. For immutable objects, typechecking in the presence of 
successive modifications of data (first assignment by the 
compiler, then modification by the user) is very difficult if 
not impossible. I don't know how to do it. The single 
initialization model (raw/cooked) used currently in regular 
immutable constructors works reasonably well and is robust.


I'd think that just letting the const/immutable postblit function 
see head-mutable fields would work.


But maybe that's way harder to implement than writing it down the 
forum. If that's so, then fair enough. I know that I won't be 
able to implement it.


2. For shared objects, the part done by the compiler and the 
part done by this(this) should be synchronized together. This 
makes it impossible for the user to e.g. define a struct that 
gets copied atomically.


Interesting. I've got no armchair expertise on this one.

There'd be an additional issue - this(this) is non-templated, 
which requires combinatorial additions when qualifiers are 
present on the source or destination side.


I think I don't understand this one. Could you give an example in 
code?


Are you saying that we'd need to define all these:

this(this)
this(this) const
this(this) immutable

even if they do the same thing? Wouldn't `this(this) inout` take 
care of this?

Re: Optional parameters?

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-04-01 17:54, Steven Schveighoffer wrote:
I currently have a situation where I want to have a function that 
accepts a parameter optionally.


I thought maybe Nullable!int might work:

void foo(Nullable!int) {}

void main()
{
    foo(1); // error
    int x;
    foo(x); // error
}

Apparently, I have to manually wrap an int to get it to pass. In other 
languages that support optional types, I can do such things, and it 
works without issues.


I know I can do things like this:

void foo(int x) { return foo(nullable(x)); }

But I'd rather avoid such things if possible. Is there a way around 
this? Seems rather limiting that I can do:


Nullable!int x = 1;

but I can't implicitly convert 1 to a Nullable!int for function calls.


Yeah, D doesn't allow user defined implicit conversions, which I think 
is required for this. I would make function overloading even more 
complex than it is today.


Although it would be really handy for cases like this.

--
/Jacob Carlborg

Optional parameters?

[Steven Schveighoffer via Digitalmars-d-learn]

I currently have a situation where I want to have a function that 
accepts a parameter optionally.


I thought maybe Nullable!int might work:

void foo(Nullable!int) {}

void main()
{
   foo(1); // error
   int x;
   foo(x); // error
}

Apparently, I have to manually wrap an int to get it to pass. In other 
languages that support optional types, I can do such things, and it 
works without issues.


I know I can do things like this:

void foo(int x) { return foo(nullable(x)); }

But I'd rather avoid such things if possible. Is there a way around 
this? Seems rather limiting that I can do:


Nullable!int x = 1;

but I can't implicitly convert 1 to a Nullable!int for function calls.

-Steve

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 10:31:46 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 4/1/18 9:37 AM, Jonathan M Davis wrote:
> > One issue is that postblit constructors fundamentally don't work with
> > const.
> Actually they do...

How so? In the postblit, you're dealing with a copy of an object where
everything is already initialized. Mutating the object would violate const.
It could be made to work for primitive types that the compiler understands
and knows that the member variable is truly independent - e.g. it could be
allowed to mutate an int, or it could be allowed to mutate a pointer while
treating what it points to as const, but as soon as you're dealing with
user-defined types, you're screwed - especially if you're dealing with
something like a struct with a user-defined opAssign. You're reading an
existing value and then mutating it, and it has to be at least tail-const,
because the original was const - and tail-const is pretty meaningless for
structs and can't really be represented in the type system for classes. So,
I don't see how postblit could be made to work with a const object of any
real complexity. It can be made to work in some corner cases but not in
general.

Kenji worked on a solution to the problem with const and postblit several
years ago (and I'm not sure how close he got to really solving it), but as I
recall, you and Walter shot it down because it was overly complicated. How
are you proposing that const work with postblit?

- Jonathan M Davis

Re: CTFE ^^ (pow)

[Joakim via Digitalmars-d]

Been meaning to respond to this for some time now, finally got 
around to it. :)


On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote:
On 18 March 2018 at 17:28, Joakim via Digitalmars-d 
 wrote:


Perhaps the community simply has different priorities than 
you? For example, my Android port has never gotten much use 
either, which is fine as I primarily did that work for myself.


Nevertheless, you have to think of D as like working in a 
startup: if you see something that you think needs doing, you 
have to drive it yourself or it will never get done. Pretty 
much the same for most any OSS project too.


This is such an easy and readily-deploy-able response here.
What you say is true, and I totally understand this... but at 
the same
time, that's not actually the relationship I want to have with 
my
tool. A startup probably shouldn't still be a startup 10 years 
later.


Then maybe D is the wrong tool for you?  Almost any tool that I 
know of, you either have to pay a ton of money or be willing to 
invest a ton of your development time to maintain yourself.  D is 
in the latter camp for anything serious, which is why Weka 
contracts with the ldc devs and Sociomantic wrote their own 
garbage collector and Ocean @nogc libraries.


There are a few exceptions to this rule, ie clang mostly 
open-sourced by Apple and available for free, but almost no tools 
work that way. You seem to expect D to work like clang without 
having an Apple behind it, only the largest company on the 
planet! :)


In your case, doing the android work was obviously an interest 
you had

on the side, and you gain something from the work itself.
I have a small amount of that, but that's not where I'm at, and 
it
never has been. I want to use D to do my job, because I'm fed 
up with
C++. I want to engage in D the way I think D should **EXPECT** 
it's
users to engage in D; as an end-user, who uses the tool to get 
their

jobs done.


Great, you can all pay Walter $100-500 like you do for all your 
other tools and then you can get your paying job done. Oh, you 
never paid Walter anything? Well, then the expectations are 
different.


If D is a large-ish scale hobby project among a bunch of people 
with
mutual interests, then that should be more clearly 
communicated, but I
don't think that's the intent, and I feel perfectly fine 
interacting

with D in the way D is intended to be interacted with.


It has elements of that, but it's growing into something more, 
particularly with the fundraising efforts recently.  Whether they 
will succeed, nobody can predict.


Incidentally, this particular work I'm doing is on a multimedia 
library intended for the community... so I really am truly 
trying to contribute something of value!! But like most of my 
projects, I tend to get blocked at some point, and then it goes 
on hold indefinitely.


I know, I'm not saying your ultimate goal is selfish in this 
case.  However, if you want to use it in your job, that's a 
different matter.


On Monday, 19 March 2018 at 01:15:28 UTC, Manu wrote:
On 18 March 2018 at 17:55, Jonathan M Davis via Digitalmars-d 
 wrote:
I definitely agree with this. If the folks fixing stuff don't 
have the same priorities as you, then there's a high risk that 
what you want to be fixed won't get fixed, and that's often 
how things go with open source projects.


And here it comes again!
I understand the reality, and echo-ing statement sounds so good 
to the
community... but it's a terrible opinion to propagate if the 
goal is

for D to be successful.
You're effectively saying "D is a hobby/toy, therefore you 
can't bank
on it with confidence". If I weren't a deluded zealot, there's 
NO WAY
I'd let my business invest in this technology when the crowd 
endlessly

repeats this sentiment.


Then don't, but that's the reality of where D's at. There's a 
wide spectrum between hobby/toy and production tool that 
conservative businesses pay thousands of dollars for, so they can 
make sure it's super-stable and supported.  D is somewhere in 
between, closer to the former than the latter.  That means it's 
more suited for startups like Sociomantic or Weka and not for 
old-school conglomerates like HP.  If you want the stability of 
the latter while paying nothing, it's your expectations that are 
wrong.


So, while it IS a practical reality, there needs to be very 
strong

motivation from the community (and organisation) to combat that
practical reality.
I would strongly suggest; never say a sentence like this again. 
It's
the wrong attitude, and it gives an undesirable impression to 
users.
(assuming the goal is for D to be successful, and not a fun 
hobby for

the devs)


It is the _truth_, so it should be repeatedly said.

But at the same time, if you come to D, see all kinds of great 
things about it, and think that it's going to be fantastic but 
keep running into things that cause you problems when you try 
to use D, and 

Re: Deprecating this(this)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 1 April 2018 at 14:34:01 UTC, ag0aep6g wrote:

On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote:
One issue is that postblit constructors fundamentally don't 
work with const. The problem is that a postblit constructor 
works by copying the object and _then_ mutating it, and you 
can't mutate a const object.


I'm not so sure if that's fundamental. Can't we just say that 
the copy is head-mutable at the time when the postblit function 
is called, and it only becomes fully const after that?


The destination can't be const/immutable already, or you 
wouldn't be able to write there anyway.


Ah, you said it much better than I did.

Re: Deprecating this(this)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu 
wrote:
There's a mix of fundamental flaws and bugs. I'll get to the 
flaws in a second. About the bugs: people have altered their 
code in various ways to work with the bizarre semantics of 
this(this). Now, if we fix various bugs in this(this) by 
virtually redefining it, then we'll break a lot of code in a 
lot of ways. To wit, we fixed a small issue and it already 
created problems: https://github.com/dlang/dmd/pull/8032. That 
didn't contribute to the decision but is quite illustrative.


I found two fundamental flaws with this(this):

1. For immutable objects, typechecking in the presence of 
successive modifications of data (first assignment by the 
compiler, then modification by the user) is very difficult if 
not impossible. I don't know how to do it. The single 
initialization model (raw/cooked) used currently in regular 
immutable constructors works reasonably well and is robust.


2. For shared objects, the part done by the compiler and the 
part done by this(this) should be synchronized together. This 
makes it impossible for the user to e.g. define a struct that 
gets copied atomically.




See my other reply: but why is it necessary to consider the blit 
logically distinct from the postblit w.r.t to program flow 
observability?


for 1. consider
immutable foo = ...;
immutable bar = foo;
to be
immutable foo = ...;
immutable bar = () {mutable _ = bitcopy(foo); _.__postblit(); 
return _;}();


for 2. you would have to synchronize anyway for shared, it makes 
no difference.


There'd be an additional issue - this(this) is non-templated, 
which requires combinatorial additions when qualifiers are 
present on the source or destination side.


(Perhaps this is what you're referring to, but all you have said 
so far is "this doesn't work and we need to fix it") the post 
blit is surely like a destructor: there's only one way to do it, 
irrespective of the attributes, especially of the intermediate is 
considered mutable until the end of post blit, like static module 
constructors initialising global immutables.


Please note that fixing one or two of these issues doesn't make 
this(this) viable - I'm mentioning various issues, each of 
which is a showstopper. Nevertheless knowing them is necessary 
so we don't make the same mistake again!



Andrei


I agree that we should fix any type checking bugs that may be 
present, and that we should strive to not make the same mistake 
twice, however I wouldn't call either of the above cases a 
showstopper. You will need to show more of what is broken and why 
it is broken given the expected breakage.

Re: Deprecating this(this)

[Nicholas Wilson via Digitalmars-d]

On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote:
One issue is that postblit constructors fundamentally don't 
work with const. The problem is that a postblit constructor 
works by copying the object and _then_ mutating it, and you 
can't mutate a const object. To cleanly deal with const, you 
need something more like a copy constructor where you 
initialize it with the adjusted values directly rather than 
mutating the copy.


I've always wondered about that, is the difference between that 
anything more than philosophical? Put another way if a this(this) 
is weakly pure, is there any safety issues with the compiler 
permitting the mutation on a (non-shared? not sure if this would 
be a requirement) const object? I'm not sure what the spec says, 
but if you take the view that the const object is no fully 
initialised until the postblit is done, then I don't see the 
problem.

Re: __has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 9:39 AM, Uknown wrote:

On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu wrote:

On 4/1/18 2:22 AM, Uknown wrote:

[...]


That's a great initiative, and a worthy trait for the stdlib. I think 
you'd have an easier time if you reasoned from the other end. A 
function is strongly pure if all of the following are true:


[...]


I got a working implementation that satisfies your requirements in about 
60 lines.

I will make a Pull Request as soon as I write the Docs and unittests.

Here's the implementation: https://run.dlang.io/is/kVpv36


Terrific, thanks!!

Re: __has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 9:46 AM, Jonathan M Davis wrote:

In principle, a function which has const parameters could be treated as
strongly pure if it's given immutable arguments


I want to give coders leeway to cheat on that. I'll explain later 
(allocators).

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote:
One issue is that postblit constructors fundamentally don't 
work with const. The problem is that a postblit constructor 
works by copying the object and _then_ mutating it, and you 
can't mutate a const object.


I'm not so sure if that's fundamental. Can't we just say that the 
copy is head-mutable at the time when the postblit function is 
called, and it only becomes fully const after that?


The destination can't be const/immutable already, or you wouldn't 
be able to write there anyway.

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 9:37 AM, Jonathan M Davis wrote:

One issue is that postblit constructors fundamentally don't work with const.


Actually they do...

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 8:55 AM, ag0aep6g wrote:

On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:

On 3/31/18 8:32 PM, H. S. Teoh wrote:

[...]

What exactly is it about this(this) that blocks us from doing that?


See the updated docs. Too many bugs in design and implementation.


Removing this(this) is going to be a huge breaking change far bigger
than, say, removing autodecoding ever will be.


We're not removing it as much as evolving it: we define an alternate 
copying mechanism, and once that is in tip-top shape, we deprecate 
this(this).


Is there a fundamental flaw in the postblit idea, or are you just going 
to give postblit a new syntax, and try to avoid all the issues that 
`this(this)` currently has?


If there's a fundamental flaw, I'd be interested in what it is. I can't 
make it out in your additions to the spec, if it's in there. I can see 
that `this(this)` is  a mess, but it also looks like a lot could be 
fixed. For example, how it interacts with const/immutable is ridiculous, 
but that could probably be fixed.


If you're just going for a clean slate, I can see the appeal. You avoid 
dealing with the hard breakage that fixing `this(this)` would most 
probably bring.


There's a mix of fundamental flaws and bugs. I'll get to the flaws in a 
second. About the bugs: people have altered their code in various ways 
to work with the bizarre semantics of this(this). Now, if we fix various 
bugs in this(this) by virtually redefining it, then we'll break a lot of 
code in a lot of ways. To wit, we fixed a small issue and it already 
created problems: https://github.com/dlang/dmd/pull/8032. That didn't 
contribute to the decision but is quite illustrative.


I found two fundamental flaws with this(this):

1. For immutable objects, typechecking in the presence of successive 
modifications of data (first assignment by the compiler, then 
modification by the user) is very difficult if not impossible. I don't 
know how to do it. The single initialization model (raw/cooked) used 
currently in regular immutable constructors works reasonably well and is 
robust.


2. For shared objects, the part done by the compiler and the part done 
by this(this) should be synchronized together. This makes it impossible 
for the user to e.g. define a struct that gets copied atomically.


There'd be an additional issue - this(this) is non-templated, which 
requires combinatorial additions when qualifiers are present on the 
source or destination side.


Please note that fixing one or two of these issues doesn't make 
this(this) viable - I'm mentioning various issues, each of which is a 
showstopper. Nevertheless knowing them is necessary so we don't make the 
same mistake again!



Andrei

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

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-03-30 08:53, Dmitry Olshansky wrote:

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


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


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


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


I completely agree. I was quite surprised when I started to use libclang 
and the only way to pass options to the library (which are usually 
command line flags) was to pass it as an array of command line options. 
This is the C API, the C++ API is more advanced.


--
/Jacob Carlborg

Re: __has_side_effects

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 06:23:40 Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 4/1/18 2:22 AM, Uknown wrote:
> > On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote:
> >> [...]
> >>
> >> I knew I was missing something. Fixed it, thanks
> >>
> >> https://run.dlang.io/is/tZeZrP
> >
> > Sorry for the spam, but I also managed to miss `immutable`, `const` and
> > when T has mutable indirections
> >
> > Final version that I'm sure covers all the cases:
> >
> > https://run.dlang.io/is/kGoU4X
>
> That's a great initiative, and a worthy trait for the stdlib. I think
> you'd have an easier time if you reasoned from the other end. A function
> is strongly pure if all of the following are true:
>
> * Each parameter:
>- is immutable, OR
>- can be converted automatically to immutable (i.e. has no mutable
> indirections) AND is passed by value
> * The return type:
>- is immutable, OR
>- can be converted automatically to immutable
>
> (We don't want to give const this much power yet for other reasons.)

In principle, a function which has const parameters could be treated as
strongly pure if it's given immutable arguments, but I don't believe that
the language does that, and in that case, you couldn't just test a function
to see if it was strongly pure, since in some cases, it would depend on the
arguments. So, to test for strong purity, you'd need both the function and
the arguments, meaning that it wouldn't so much be the case that a function
was strongly pure as a function call was strongly pure. Such a change to
strong purity would increase the number of optimizations that could be based
on pure, but I don't know that it would be worth it, especially since it
would then be much harder to have a trait like this, and functions are so
rarely called with the same arguments in the same expression or statement
that I'm not sure that such a change would really add much in the way of
optimization opportunities.

- Jonathan M Davis

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

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

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

--- Comment #13 from Ketmar Dark  ---
>Think D2.042
easy deal: http://downloads.dlang.org/releases/2010/

[pts/44:ketmar]:D/_old_dmd% ./dmd2/linux/bin/dmd
Digital Mars D Compiler v2.042
Copyright (c) 1999-2010 by Digital Mars written by Walter Bright

[pts/44:ketmar]:D/_old_dmd% ./dmd2/linux/bin/dmd -c test.d
test.d(2): Declaration expected, not 'foreach'
test.d(2): Declaration expected, not '__traits'
test.d(5): unrecognized declaration

exactly the same error with 2.039. should i go even further back in time? or,
fast-forward to 2.059: still the same thing. it. never. worked.

--

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 2:22 AM, Uknown wrote:

[...]


That's a great initiative, and a worthy trait for the stdlib. I 
think you'd have an easier time if you reasoned from the other 
end. A function is strongly pure if all of the following are 
true:


[...]


I got a working implementation that satisfies your requirements 
in about 60 lines.
I will make a Pull Request as soon as I write the Docs and 
unittests.


Here's the implementation: https://run.dlang.io/is/kVpv36

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 14:55:07 ag0aep6g via Digitalmars-d wrote:
> On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:
> > On 3/31/18 8:32 PM, H. S. Teoh wrote:
> [...]
>
> >> What exactly is it about this(this) that blocks us from doing that?
> >
> > See the updated docs. Too many bugs in design and implementation.
> >
> >> Removing this(this) is going to be a huge breaking change far bigger
> >> than, say, removing autodecoding ever will be.
> >
> > We're not removing it as much as evolving it: we define an alternate
> > copying mechanism, and once that is in tip-top shape, we deprecate
> > this(this).
>
> Is there a fundamental flaw in the postblit idea, or are you just going
> to give postblit a new syntax, and try to avoid all the issues that
> `this(this)` currently has?
>
> If there's a fundamental flaw, I'd be interested in what it is. I can't
> make it out in your additions to the spec, if it's in there. I can see
> that `this(this)` is  a mess, but it also looks like a lot could be
> fixed. For example, how it interacts with const/immutable is ridiculous,
> but that could probably be fixed.

One issue is that postblit constructors fundamentally don't work with const.
The problem is that a postblit constructor works by copying the object and
_then_ mutating it, and you can't mutate a const object. To cleanly deal
with const, you need something more like a copy constructor where you
initialize it with the adjusted values directly rather than mutating the
copy.

> If you're just going for a clean slate, I can see the appeal. You avoid
> dealing with the hard breakage that fixing `this(this)` would most
> probably bring.

Avoiding any breakage would be ideal, but it's unlikely that that can be
done if we want to make copying const objects work properly - not unless we
did something like use postblit constructors for mutable objects and copy
constructors for const objects, and that would just cause other problems
(including having to duplicate the code that deals with copying an object if
it's going to work with const). On the bright side, if we're replacing
postblit constructors with some other type of constructor for copying, it
should be a pretty straightforward process. But there isn't much point in
worrying about how much breakage there's going to be before we really know
where we want to go with this. At this point, it's just clear that as things
stand, postblit constructors have some definite problems (some which are
implementation issues and some which are language design issues), and based
on past discussions on this and previous attempts to fix some of the
problems with postblit constructors, it seems pretty unlikely that we can
fully fix postblit constructors. I'm sure that we could fix some of the
issues, but others (most notably, the issues with const) seem pretty
intractable.

- Jonathan M Davis

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

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

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

--- Comment #12 from Manu  ---
I'd love to paste code... But I wrote it in 2012 at a company I don't work at
anymore.
Think D2.042...

I'll see what I can do when I'm not in bed on a phone. But I have no idea what
now I can offer. I used to take function prototypes at top level, and mixin
their bodies at the same scope. My entire system was based on this.

They didn't fly me to dconf to talk about code that didn't compile.

--

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

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

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

--- Comment #11 from Ketmar Dark  ---
  module test;
  foreach(m; __traits(allMembers, test))
  {
pragma(msg, m);
  }

rdmd --force --compiler=ldc --eval="pragma(msg, __VERSION__);"
2073L

rdmd --force --compiler=ldc -c test.d
test.d(2): Error: declaration expected, not 'foreach'
test.d(2): Error: declaration expected, not '__traits'
test.d(5): Error: unrecognized declaration

2.073 is *way* before `static foreach`.

so please, code sample and compiler version. if it used to work, and now
doesn't, this is clearly a regression nobody noticed.

the same for old `foreach` code that doesn't work as it used to work before,
please.

--

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

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

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

--- Comment #10 from Manu  ---
Remove the 'static' from my OP and you have it.

It definitely worked. They flew me to dconf in 2013 and I gave a whole lecture
about it.
I don't work there anymore, so I don't have the code. I was starting to write a
new version.

Emitting an error instructing me to insert 'static' is at least once change in
old foreach.

--

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

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

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

--- Comment #9 from Ketmar Dark  ---
>Non-static foreach doesn't seem to be the same.
example, please. *nothing* was changed in old foreach.

>And it definitely worked at top level.
example, please. i have several different compiler versions at hand, starting
from 2.073 (WAY before static foreach), and top-level foreach doesn't work in
all of them. please, give example code and compiler version where it worked.
thank you.

--

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

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

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

--- Comment #8 from Manu  ---
Non-static foreach doesn't seem to be the same. There are new errors with old
usage of foreach instructing to use static foreach instead.

And it definitely worked at top level. I was using it to generate top level
binding stub functions almost as long as I've been using D.

It would be inside a mixin template mixed in at top level, that's all.

--

Re: Deprecating this(this)

[ag0aep6g via Digitalmars-d]

On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:

On 3/31/18 8:32 PM, H. S. Teoh wrote:

[...]

What exactly is it about this(this) that blocks us from doing that?


See the updated docs. Too many bugs in design and implementation.


Removing this(this) is going to be a huge breaking change far bigger
than, say, removing autodecoding ever will be.


We're not removing it as much as evolving it: we define an alternate 
copying mechanism, and once that is in tip-top shape, we deprecate 
this(this).


Is there a fundamental flaw in the postblit idea, or are you just going 
to give postblit a new syntax, and try to avoid all the issues that 
`this(this)` currently has?


If there's a fundamental flaw, I'd be interested in what it is. I can't 
make it out in your additions to the spec, if it's in there. I can see 
that `this(this)` is  a mess, but it also looks like a lot could be 
fixed. For example, how it interacts with const/immutable is ridiculous, 
but that could probably be fixed.


If you're just going for a clean slate, I can see the appeal. You avoid 
dealing with the hard breakage that fixing `this(this)` would most 
probably bring.

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

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

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

--- Comment #7 from Ketmar Dark  ---
`foreach` never worked at the top level. and non-static forach works *exactly*
the same as before. you are clearly has a very different compiler than the rest
of us.

--

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

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

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

--- Comment #6 from Manu  ---
I used 'foreach', which doesn't work anymore.
Since static foreach was added, the non-static one doesn't work the same.
static foreach should to all the static stuff that foreach used to do.

--

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 12:23:29 Per Nordlöw via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote:
> > Another potential issue is whether any of this does or should
> > relate to
> >
> > https://github.com/dlang/DIPs/pull/109
> >
> > and it's solution for hooking into to moves. I'm not at all
> > sure that what happens with that needs to be related to this at
> > all, but it might.
> >
> > - Jonathan M Davis
>
> And before we think about `opMove` we should, IMO, make the
> compiler pass by move in more cases, for instance, in range
> constructors such as
>
> this(Source source)
> {
>  this.source = source; // last occurrence of `source` can be
> moved
> }
>
> I'd be happy to help out with adding this in dmd. Andrei has
> already showed interest in this idea.

I don't see what that has to do with opMove other than the fact that in such
cases, you'd then end up with opMove being called instead of the postblit
constructor. It seems to me that whether opMove is part of the language or
not when such improvements are made is irrelevant. They should be able to be
done independently of one other.

As I understand it, the motivations behind opMove really have nothing to do
with how often moves are made vs copying. It has to do with types that have
serious issues if they're moved. The Weka guys (and probably others) have
use cases where the fact that an object is moved without any way for them to
detect it and do stuff like update pointers to the object is a serious
problem. If anything, their use case might be better off right now if _no_
moves were ever done (at least until something like opMove is in the
language), since the moves result in bugs.

- Jonathan M Davis

Re: Deprecating this(this)

[Jonathan M Davis via Digitalmars-d]

On Sunday, April 01, 2018 11:37:21 Guillaume Piolat via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote:
> > So, I think that the only large-scale benefit thet exists for
> > pure and really can exist for pure is the fact that you know
> > that the function doesn't access global, mutable state.
> > Everything else it does is just gravy and too limited to be a
> > "large-scale" benefit. Certainly, optimizations are clearly
> > _not_ the main benefit of pure, since they almost don't exist.
> > But over time, we have managed to add more gravy here and there
> > as we've figured out assumptions that can be made based on pure
> > (like the case where we can convert the result of a pure
> > function to immutable).
> >
> > - Jonathan M Davis
>
> Great write-up.
>
> Why keep pure when the benefits obviously don't outweight the
> costs?
> Here is what I interpret reading this: "lost productivity".

Personally, I don't think that the costs outweigh the benefits. Yes, if your
primary goal is optimizations, then pure falls flat on its face, but
personally, I think that the fact that pure allows you to prove that a
function doesn't access any global, mutable state except through its
arguments is quite valuable. There are still some things in druntime and
Phobos which don't work with pure like they should, but in general, I
haven't found that it's really a big problem. Some code can't be pure, and
that's life, but a _lot_ can be. If anything, I find that const is the
attribute that causes problems, not pure.

But if you don't want to use pure, then don't use pure. Nothing is forcing
you to use it, and if someone else insists on making their code work with
pure, it's only a problem for you if they're trying to call your code, and
they complain about the fact that your code doesn't work with pure.
Certainly, code that isn't pure has no problems calling code that is, so if
other folks go to the effort of making their code work with pure, it won't
cause you problems.

- Jonathan M Davis

Re: Deprecating this(this)

[Per Nordlöw via Digitalmars-d]

On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote:
Another potential issue is whether any of this does or should 
relate to


https://github.com/dlang/DIPs/pull/109

and it's solution for hooking into to moves. I'm not at all 
sure that what happens with that needs to be related to this at 
all, but it might.


- Jonathan M Davis


And before we think about `opMove` we should, IMO, make the 
compiler pass by move in more cases, for instance, in range 
constructors such as


this(Source source)
{
this.source = source; // last occurrence of `source` can be 
moved

}

I'd be happy to help out with adding this in dmd. Andrei has 
already showed interest in this idea.

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

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

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

--- Comment #5 from Ketmar Dark  ---
[i]>I've been using this for almost 10 years[/i]
static foreach? so you really have a time machine, or a specially-crafted
compiler version you never gave others?! please, can you show us the 10 yo code
with `static foreach`, and the 10 yo old compiler you used to compile it?

this is normal thing for new language feature: some cases are missed. it will
eventually be fixed, and in the meantime you can write the code like us, mere
mortals did for those 10 years: without `static foreach`.

--

Re: Deprecating this(this)

[Guillaume Piolat via Digitalmars-d]

On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote:
So, I think that the only large-scale benefit thet exists for 
pure and really can exist for pure is the fact that you know 
that the function doesn't access global, mutable state. 
Everything else it does is just gravy and too limited to be a 
"large-scale" benefit. Certainly, optimizations are clearly 
_not_ the main benefit of pure, since they almost don't exist. 
But over time, we have managed to add more gravy here and there 
as we've figured out assumptions that can be made based on pure 
(like the case where we can convert the result of a pure 
function to immutable).


- Jonathan M Davis


Great write-up.

Why keep pure when the benefits obviously don't outweight the 
costs?

Here is what I interpret reading this: "lost productivity".

Re: Deprecating this(this)

[Guillaume Piolat via Digitalmars-d]

On Saturday, 31 March 2018 at 23:38:06 UTC, Andrei Alexandrescu 
wrote:


* immutable and const are very difficult, but we have an attack 
(assuming copy construction gets taken care of)


* pure is difficult



How about removing pure, const and immutable?

Re: Deprecating this(this)

[Patrick Schluter via Digitalmars-d]

On Sunday, 1 April 2018 at 10:49:22 UTC, bachmeier wrote:

On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote:
This seems really sudden, april fool's joke? Not really sure, 
as there are real problems with this(this)...


What I was wondering too. I mean, breaking changes just don't 
happen to this language. Now there will be, without even an 
indication of how existing code would have to be rewritten, or 
how this large-scale breakage is different than the breakages 
that just can't happen because reasons. I guess that's why 
there's always the disclaimer, "We'll only break code if 
there's a really good reason." That reason is "in case we want 
to".


Nothing has been lay out yet and people are already freaking out. 
No wonder nothing gets done anymore.

Re: Fast GC allocation of many small objects

[Alexandru jercaianu via Digitalmars-d-learn]

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote:
On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu 
wrote:

Hello,

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

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

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


Thanks!

Is a `minAlign` of 16 recommended over 8 when allocating 
classes or arrays?

Hi,
I'm glad it was helpful.
To be honest, I don't know which alignment would be better and it 
probably depends on your machine.
This here says that 16 would work just fine [1] so I would go 
with that.


[1] - 
https://dlang.org/library/std/experimental/allocator/common/platform_alignment.html

Re: Deprecating this(this)

[bachmeier via Digitalmars-d]

On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote:
This seems really sudden, april fool's joke? Not really sure, 
as there are real problems with this(this)...


What I was wondering too. I mean, breaking changes just don't 
happen to this language. Now there will be, without even an 
indication of how existing code would have to be rewritten, or 
how this large-scale breakage is different than the breakages 
that just can't happen because reasons. I guess that's why 
there's always the disclaimer, "We'll only break code if there's 
a really good reason." That reason is "in case we want to".

Re: Deprecating this(this)

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 6:04 AM, Johannes Loher wrote:

This seems really sudden, april fool's joke? Not really sure, as there
are real problems with this(this)...


I'm glad I've sent it yesterday then at least in my time zone :o).

This looks sudden but isn't. Eduard and I have been blocked by this 
problem seriously whilst working on the collections library.



Andrei

Re: __has_side_effects

[Andrei Alexandrescu via Digitalmars-d]

On 4/1/18 2:22 AM, Uknown wrote:

On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote:

[...]

I knew I was missing something. Fixed it, thanks

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


Sorry for the spam, but I also managed to miss `immutable`, `const` and 
when T has mutable indirections


Final version that I'm sure covers all the cases:

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


That's a great initiative, and a worthy trait for the stdlib. I think 
you'd have an easier time if you reasoned from the other end. A function 
is strongly pure if all of the following are true:


* Each parameter:
  - is immutable, OR
  - can be converted automatically to immutable (i.e. has no mutable 
indirections) AND is passed by value

* The return type:
  - is immutable, OR
  - can be converted automatically to immutable

(We don't want to give const this much power yet for other reasons.)

The template should support taking the function name as a string, too, 
and the parameter types so as to easily distinguish across overloads.


This would be a great addition to std.traits. Once we have it, we'll 
have a precise unified definition of strongly pure across the language 
spec and the stdlib definition. Please follow up, thanks!



Andrei

Re: Deprecating this(this)

[Johannes Loher via Digitalmars-d]

Am 01.04.2018 um 01:38 schrieb Andrei Alexandrescu:
> We need to have a simple recipe on how to define a canonical object.
> That would include requirements such as:
> 
> * should work with mutable, const, immutable, and shared
> * the right way to define constructor(s)
> * the right way to define copying
> * the right way to define destructor(s)
> 
> I've asked my student Razvan to document the behavior of this(this). His
> work:
> 
> https://github.com/dlang/dmd/pull/8055
> https://github.com/dlang/dlang.org/pull/2281
> https://github.com/dlang/dlang.org/pull/2299
> 
> ... reveals a puzzling array of behaviors. Sometimes the typechecking is
> wrong, too.
> 
> I think it's very important for us to have a simple, correct, and
> canonical way of defining structs in the D language that work with the
> language features: qualifiers, pure, safe, and nogc.
> 
> Once we have that, we can encapsulate desirable abstractions (such as
> @nogc safe collections that work in pure code), regardless of how
> difficult their implementations might be. It seems that currently
> this(this) does not allow us to do that.
> 
> Eduard, another student I work with, has made steps toward a collections
> library that rant into difficulties:
> 
> * @safe is achievable with relative ease
> 
> * immutable and const are very difficult, but we have an attack
> (assuming copy construction gets taken care of)
> 
> * @nogc is doable with a couple of conventions for allocators
> 
> * pure is difficult
> 
> * making them work together is very difficult
> 
> We need to offer features, tools, and guidance toward creating simple
> encapsulated types that work well with D's own abstractions. Once we
> have that we can build libraries to work satisfactorily for any domain.
> 
> I think the way to move forward is to deprecate this(this) entirely and
> create a DIP that allows people to define truly encapsulated structs.
> This is important, urgent, and of huge impact.
> 
> I am looking for folks to assist me in creating a DIP for that. There
> will be a _lot_ of work involved, so don't take it lightly.
> 
> 
> Thanks,
> 
> Andrei

This seems really sudden, april fool's joke? Not really sure, as there
are real problems with this(this)...

[Issue 18652] hashOf example doesn't compile

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

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

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

   What|Removed |Added

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

--

[Issue 18652] hashOf example doesn't compile

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

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

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

https://github.com/dlang/druntime/commit/41eb363d75f38bace0a9a1f8e39bd5805cd98c61
Fix Issue 18652 - hashOf example doesn't compile

https://github.com/dlang/druntime/commit/11aecf478a6a23dca1cee27fad5dac052cb0e0ba
Merge pull request #2152 from WalterBright/fix18652

Issue 18652 - hashOf example doesn't compile

--

Re: does it scale to have 1 person approve of all phobos additions?

[Joakim via Digitalmars-d]

On Sunday, 1 April 2018 at 08:07:09 UTC, John Belmonte wrote:

FWIW, my dmd bug fix PR is getting languish-y.

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

Ideally a good bug fix shouldn't sit around for a week.  Why 
I'd call this one good:


* in addition to reported bug (struct initializer 
incorrectly parsed as function literal), a read of the code 
uncovered converse as well (function literal incorrectly parsed 
as struct literal).  PR fixes both and adds test cases.


* documents additional ambiguous parser cases, and why we 
resolve the ambiguous cases as we do, and how to work around 
it.  Added unit tests to confirm handling of ambiguous cases.


What went well:  appveyor flagged a regression which sent me 
back to the drawing board, resulting in a much better fix


Regards,
--John


I'd say your PR has been handled well: you received feedback 
pretty quickly and it has been approved by a member of the core 
team.  It's likely only been sitting unmerged in a waiting period 
to give others time to weigh in, as not everybody has time to 
check PRs regularly.

Re: does it scale to have 1 person approve of all phobos additions?

[John Belmonte via Digitalmars-d]

FWIW, my dmd bug fix PR is getting languish-y.

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

Ideally a good bug fix shouldn't sit around for a week.  Why I'd 
call this one good:


* in addition to reported bug (struct initializer incorrectly 
parsed as function literal), a read of the code uncovered 
converse as well (function literal incorrectly parsed as struct 
literal).  PR fixes both and adds test cases.


* documents additional ambiguous parser cases, and why we 
resolve the ambiguous cases as we do, and how to work around it.  
Added unit tests to confirm handling of ambiguous cases.


What went well:  appveyor flagged a regression which sent me back 
to the drawing board, resulting in a much better fix


Regards,
--John

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

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #4 from greenify  ---
Static foreach has been added in summer 2017 - how could you have been using
this for ten years?

(if this really is a regression, please describe it better so that everyone
understands it. Otherwise I think ketmar's assessment of this being an
oversight when static foreach was added.

--

Re: auto-decoding

[Seb via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 02:44:32 UTC, Uknown wrote:
If you want to stop auto-decoding, you can use 
std.string.representation like this:


import std.string : representation;
auto no_decode = some_string.representation;

Now no_decode wont be auto-decoded, and you can use it in place 
of some_string. You can also use std.utf to decode by graphemes 
instead.


.representation gives you an const(ubyte)[]

What you typically want is const(char)[], for this you can use 
std.utf.byCodeUnit


https://dlang.org/phobos/std_utf.html#byCodeUnit

There's also this good article:

https://tour.dlang.org/tour/en/gems/unicode

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

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

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

--- Comment #3 from Manu  ---
I barely understood a word of that post.
Point is, this used to work... I've been using this for almost 10 years to do a
bunch of codegen for stuff in module scope.

--

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote:

[...]

I knew I was missing something. Fixed it, thanks

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


Sorry for the spam, but I also managed to miss `immutable`, 
`const` and when T has mutable indirections


Final version that I'm sure covers all the cases:

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