[Issue 15579] extern(C++) interfaces/multiple-inheritance

[via Digitalmars-d-bugs]

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

--- Comment #10 from Walter Bright  ---
(In reply to Manu from comment #7)
> 3>Building bin\Debug_x64\dplug.dll...
> 3>libdep.lib(component_344_d5.obj) : fatal error LNK1179: invalid or corrupt
> file: duplicate COMDAT '??1Component@ep@@QEAA@XZ'
> [...]
> I presume that symbol exists in cpplib, but the error suggests that D is
> also emitting the same symbol somewhere?

Note the filename in the error message:

   libdep.lib(component_344_d5.obj)

You can also use 'grep' to find all instances and references to
'??1Component@ep@@QEAA@XZ'

--

Re: [dlang.org] new forum design

[Vladimir Panteleev via Digitalmars-d]

On Friday, 22 January 2016 at 16:58:56 UTC, Jacob Carlborg wrote:

On 2016-01-21 22:21, Vladimir Panteleev wrote:


OK, I added it back.


The "Replies" column is still wider than it needs to be. Here's 
an example [1]. The green part is the padding, which looks 
fine. But why is there some much extra space in the blue part? 
If you open both the simulator and Safari there's a "Simulator" 
menu item in the "Develop" menu in Safari. You might need to 
enable the develop menu in the preferences pane (Safari -> 
Preferences -> Advanced -> Show Develop menu in bar).


Alternatively could we come up with a symbol or icon instead of 
the text "Replies", assuming that's why it's so wide?


It is not wide because of the column heading, but because of the 
second "(123 new)" line that can appear in partially-read 
threads. And if we word-break that into two lines, that will 
increase the height of each column.


Maybe we could just hide the " new" for very narrow screens...


[1] http://imgur.com/oQHcnTK


The font size looks larger than I recall seeing it in the iOS 
simulator. I'm switching OSes so can't look at the moment though.


I'm thinking that the end-all solution would probably be a font 
size adjustment setting.

Re: DIP 88: Simple form of named parameters

[default0 via Digitalmars-d]

On Sunday, 24 January 2016 at 02:51:43 UTC, Jonathan M Davis 
wrote:
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Regardless, I for one, hope that we never have named arguments. 
It's just one more thing that's then part of the function's 
signature that you can't change without breaking code and will 
cause that much more bikeshedding. At least right now, 
parameter names don't matter much, whereas if they're part of 
the API, then they're open to all of the issues that function 
naming has.


And while I appreciate that this DIP does not make named 
arguments the default behavior for a function, making it up to 
the library writer whether they support named arguments or not 
is likely to create a lot of bikeshedding and debates over 
whether a particular function or library should support named 
arguments. Personally, I'd never use them under any 
circumstances.


- Jonathan M Davis


So given this method:
void M(int a, int b = 1, int c = 2, int d = 3, int e = 4, int f = 
5, int g = 6, int h = 7, int i = 8)

{
}

You prefer calling it this way:
M(5, 1, 2, 3, 4, 5, 6, 7, 23);
As opposed to:
M(5, i: 23);

Or am I misunderstanding you?
Also consider that the two aren't even the same, if the library 
author decides to change some default values you will likely want 
to update the former call, but the latter can stay the same. Less 
of a maintenance burden.


Coming from C# where it's a 
free-for-all-every-argument-can-be-named implementation, I never 
once even heard someone complain or experience breakage because 
some parameter name changed, which makes me think that the 
possibility of breakage, while of course real, seems to not be an 
issue in practice. Judging from my own coding habits in C#, I 
rarely change parameter names anyways (about as rarely as I 
change method names) and I rarely use named arguments anyways 
(most functions I dealt with neither had many optional 
parameters, nor had "blind" parameters where the documentation 
would've been sincerely helpful).


Also consider that using named arguments is a decision made by 
the caller ("I want to document these parameters..." or "Ugh I 
don't want to pass 10.000 arguments to this function, SKIP!"), 
not the callee ("Will the user want to document these parameters? 
Hmm... it's possible!" or "Will the user want to skip these 
default values? Hmm there's at most three here, not sure if it's 
worthwhile...").


As for this DIP I don't know - it seems to be well-thought-out, 
albeit with a focus on ease of implementation rather than 
usefulness for a language user, so I don't really have a 
conclusive opinion on that.

Re: Dmd sc.ini and VS do not work well together!

[Igor via Digitalmars-d]

On Sunday, 24 January 2016 at 05:34:18 UTC, Brad Anderson wrote:

On Saturday, 23 January 2016 at 21:38:19 UTC, Igor wrote:
I feel like I am in the cave man times.  I installed Dmd2 from 
scratch. VisualD x64 project would not compile due to 
libucrt.lib not being found.


Sorry you are having trouble. The Universal CRT and Visual 
Studio 2015 are very new and I'm sure there are still some bugs 
to work out.




Ok, I hope that it will be fixed because it seems like a rather 
simple issue(location issue). I can't know if there are any other 
problems until it is fixed.




[snip]

HKLM "Software\Microsoft\Windows Kits\Installed Roots" 
"KitsRoot10"


Then searching for the latest UCRT version in a subdirectory. 
That's probably where the bug is. This is brand new detection 
however so it might be buggy.


You can see how it works here: 
https://github.com/D-Programming-Language/installer/blob/master/windows/d2-installer.nsi#L379


Would you happen to know a better way to do this?


[snip]

The installer should be modernized and provide path 
information and resolve dependencies properly before 
installing. It is clear that dmd was not designed for windows 
use.


We make updates to it pretty much every release cycle. We'd 
love some help making it bulletproof. Rock solid VS/Platform 
SDK detection is what we want but it's proved a bit trickier 
than expected (Microsoft has changed a few things up with 
different VS releases so there is not just one way to do it).



Ok, I think you need to use all the reg keys in

HKLM "Software\Microsoft\Windows Kits\Installed Roots"

and search all valid paths for the proper files. In my case, if 
that was done, it would find the proper library files.


Basically any subdirectory that has a lib file is a possible 
candidate for a lib path. This is the part!


The hard part is to figure out which are the "correct" libs. One 
can check the libs for architecture. 32-bit libs folders are 
candidates for the 32-bit build and ditto for 64-bit.


Out of those, one should determine debug versions and separate 
that, even though sc.ini doesn't seem to have this capability. 
Maybe it could be added and then dmd can choose the correct path 
for debug builds.


After than, one will have duplicates due to versioning. One could 
try and partition down further, take the latest version, or 
present the user with options at this point.


At the very least, the installer could add all possible path 
candidates to the sc.ini as comments so when one goes in and 
edits the file, they just have to try one at a time and not go 
bonkers looking for the paths. Also, allow the option to copy the 
lib files(and possibly VC linker files) into a subfolder to use 
instead. This way one can avoid even having to reinstall the kits 
or could uninstall them and still retain the libraries outside of 
the VS mess. This would avoid having to have multiple VS versions 
installed.


A simple sc.ini reconfiguration tool or re-install/modify could 
then be used to select the different build varieties.

[Issue 15600] New: Missing functions in a template struct cause linker errors instead of being caught by compiler.

[via Digitalmars-d-bugs]

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

  Issue ID: 15600
   Summary: Missing functions in a template struct cause linker
errors instead of being caught by compiler.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@atari8.info

Probably related to 14425 (but that one is marked as fixed).

The following is the most reduced case I could get:

pipeline.d:

module pipeline;

struct Pipeline(Stages...) {
  private template Component(S) {
static if (is(S == struct))
  alias Component = S;
  }

  private template PipelineBuilder(int begin, int cur, int end) {
static assert(begin <= end && begin <= cur && cur <= end && end <=
Stages.length,
  "Invalid parameters: " ~
  Stages.stringof ~ "[" ~ begin.stringof ~ "," ~ cur.stringof ~ "," ~
end.stringof ~ "]");
static if (cur < end) {
  alias Cur = Stages[cur];
  alias Lhs = PipelineBuilder!(begin, begin, cur);
  alias Rhs = PipelineBuilder!(cur + 1, cur + 1, end);
  static if (is(Component!(Lhs.Impl) _Li))
alias LhsImpl = _Li;
  static if (is(Component!(Rhs.Impl) _Ri))
alias RhsImpl = _Ri;
  static if (begin + 1 == end && is(Cur _Impl)) {
alias Impl = _Impl;
pragma(msg, "Match: ", Stages[begin].stringof);
  } else static if (cur + 1 == end && is(Cur!LhsImpl _Impl)) {
alias Impl = _Impl;
pragma(msg, "Match: ", Stages[cur .. end].stringof);
  } else static if (cur == begin && is(Cur!RhsImpl _Impl)) {
alias Impl = _Impl;
pragma(msg, "Match: ", Stages[begin .. cur + 1].stringof);
  } else static if (is(Cur!(LhsImpl, RhsImpl) _Impl)) {
alias Impl = _Impl;
pragma(msg, "Match: ", Stages[begin .. end].stringof);
  }
  static if (cur + 1 < end) {
alias Next = PipelineBuilder!(begin, cur + 1, end);
static if (is(Next.Impl))
  alias PipelineBuilder = Next;
  }
}
  }

  auto pipe(alias NextStage)() {
return Pipeline!(Stages, NextStage)();
  }

  template ImplType() {
alias Builder = PipelineBuilder!(0, 0, Stages.length);
alias ImplType = Builder.Impl;
  }

  void run()() {
alias Impl = ImplType!();
static assert(is(Impl), "Could not build pipeline out of the following list
of stages: " ~ Stages.stringof);
Impl impl;
impl.run();
  }
}

auto pipe(alias Stage1)() {
  return Pipeline!Stage1();
}

struct PullPush(Source, Sink) {
  Source source = void;
  Sink sink = void;

  void run() {
ubyte[4096] buf;
for (;;) {
  size_t n = source.pull(buf[]);
  if (n == 0)
break;
  if (sink.push(buf[0 .. n]) < n)
break;
}
  }
}

struct Foo(Source) {
  Source source;

  size_t pull(T)(T[] data) { return 0; }
  auto peek(size_t n) { return source.peek(n); }// (1)
  void consume(size_t n) {} // (2)
}

struct NullSink {
  size_t push(T)(const(T[]) buf) { return buf.length; }
}

struct NullSource {
  size_t pull(T)(T[] buf) { return 0; }
}

unittest {
  auto s = pipe!NullSource.pipe!Foo.pipe!PullPush.pipe!NullSink;
  pragma(msg, s.ImplType!().stringof); //
(3)
//  static assert(is(s.ImplType!() == PullPush!(Foo!NullSource, NullSink))); //
(4)
  s.run(); //
(5)
}



Compiling with 2.069.2 and 2.070-b2 gives the same result:

$ dmd pipeline.d -main -unittest -allinst
Match: NullSink
Match: NullSource
Match: tuple(Foo(Source))
Match: tuple((NullSource), Foo(Source), PullPush(Source, Sink), (NullSink))
Cur!(Cur!(NullSource), NullSink)
pipeline.o: In function
`_D8pipeline81__T8PullPushTS8pipeline31__T3FooTS8pipeline10NullSourceZ3FooTS8pipeline8NullSinkZ8PullPush3runMFNaNbNiNfZv':
__main.d:(.text._D8pipeline81__T8PullPushTS8pipeline31__T3FooTS8pipeline10NullSourceZ3FooTS8pipeline8NullSinkZ8PullPush3runMFNaNbNiNfZv+0x6e):
undefined reference to
`_D8pipeline31__T3FooTS8pipeline10NullSourceZ3Foo11__T4pullThZ4pullMFNaNbNiNfAhZm'
collect2: error: ld returned 1 exit status
--- errorlevel 1


The linker complains about missing function "pure nothrow @nogc @safe ulong
pipeline.Foo!(pipeline.NullSource).Foo.pull!(ubyte).pull(ubyte[])"

However, the problem is somewhere else. Uncomment (4), and you'll see that
what's actually missing is NullSource.peek();
To fix this, Foo.peek and Foo.consume ((1) and (2)) should be changed to
template functions.
Interestingly, the error is detected by compiler when the template is
instantiated directly: PullPush!(Foo!NullSource, NullSink), but not when
Pipeline.ImplType is used, although they both resolve to the same type.

--

[Issue 15579] extern(C++) interfaces/multiple-inheritance

[via Digitalmars-d-bugs]

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

--- Comment #9 from Walter Bright  ---
Trying again:

https://github.com/D-Programming-Language/dmd/pull/5364

--

Re: DIP 88: Simple form of named parameters

[Jonathan M Davis via Digitalmars-d]

On Sunday, 24 January 2016 at 10:14:53 UTC, default0 wrote:
On Sunday, 24 January 2016 at 02:51:43 UTC, Jonathan M Davis 
wrote:
On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Regardless, I for one, hope that we never have named 
arguments. It's just one more thing that's then part of the 
function's signature that you can't change without breaking 
code and will cause that much more bikeshedding. At least 
right now, parameter names don't matter much, whereas if 
they're part of the API, then they're open to all of the 
issues that function naming has.


And while I appreciate that this DIP does not make named 
arguments the default behavior for a function, making it up to 
the library writer whether they support named arguments or not 
is likely to create a lot of bikeshedding and debates over 
whether a particular function or library should support named 
arguments. Personally, I'd never use them under any 
circumstances.


- Jonathan M Davis


So given this method:
void M(int a, int b = 1, int c = 2, int d = 3, int e = 4, int f 
= 5, int g = 6, int h = 7, int i = 8)

{
}

You prefer calling it this way:
M(5, 1, 2, 3, 4, 5, 6, 7, 23);
As opposed to:
M(5, i: 23);


Anyone who wrote a function like that is just plain writing bad 
code. With that many parameters, they should be creating a struct 
to hold the values. Named arguments really only seem to help in 
cases where functions are badly designed. I don't want to use 
them in my code, and I don't want to have to deal with them in 
other people's code. And as a library writer, I don't want to 
have to argue with anyone about whether the names that I picked 
for my parameters were good or not. We already get way too much 
bikeshedding over function names as it is without adding 
parameter names into the mix.


I would strongly argue that anyone who feels the need for named 
parameters should rethink how they're designing their functions.


- Jonathan M Davis

Re: Templates, templates, templates...

[Voitech via Digitalmars-d-learn]

On Saturday, 23 January 2016 at 13:19:34 UTC, anonymous wrote:

On 23.01.2016 12:30, Voitech wrote:
Ok so i want to hold different types in LogicRule maybe 
Algebraic

implementation would do?

private alias ControllTemplate(T) =Rule!(T,ControllFlag);
private alias SymbolRule =ControllTemplate!(SymbolType);
private alias StringRule =ControllTemplate!(SymbolRule[]);
private alias LogicTemplate(T...)
=Rule!(Algebraic!(ControllTemplate(T))[],LogicFlag); <--error


You're missing an exclamation mark there, and you've got the 
order of Algebraic and ControllTemplate wrong. This compiles:


private alias LogicTemplate(T...) = 
Rule!(ControllTemplate!(Algebraic!T)[],LogicFlag);


private alias AlgebraicLogicRule = 
LogicTemplate!(SymbolRule,StringRule);


error:
Error: cannot pass type (Rule!(SymbolType, ControllFlag),
Rule!(Rule!(SymbolType, ControllFlag)[], ControllFlag)) as a 
function

argument

[...]

Is there any nicer way to handle this case ?


Instead of Algebraic you could use a common base class, or 
interface, for the Rule instantiations:


abstract class RuleBase
{
... whatever common functionality rules have ...
}
class Rule(V,F) : RuleBase { ...}

But I have to say that I'm having trouble making sense of all 
that class and template complexity, and how it helps in 
actually validating user input.


Since this is a parsing thing, you may want to look into 
writing parsers an/or using a parse generator. I think Pegged 
is the most popular one for D. 
http://code.dlang.org/packages/pegged


Hi, thanks for answering. The complexity is unnecessary as you 
said. I'm just experimenting with D language. I think i try to 
finish implementation in my own way and then will look how it may 
be done with http://code.dlang.org/packages/pegged to have a full 
spectrum of possibilities.


I added base class for Rule -> BaseRule. But this class is just a 
shell without implementation.

Is there any way to avoid this ?

Re: extern(C++) multiple inheritence

[Walter Bright via Digitalmars-d]

On 1/22/2016 5:46 PM, Manu via Digitalmars-d wrote:

I brought a work laptop home this weekend in anticipation ;)


Here ya go:

  https://github.com/D-Programming-Language/dmd/pull/5364

Be wary of:

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

and use the workaround as necessary. This is lower priority, so I won't be 
dealing with it for a bit.

Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

Re: Last revision of phobos and druntime that actually compile with cdmd

[Daniel Murphy via Digitalmars-d]

On 25/01/2016 2:55 AM, Benjamin Thaut wrote:

I tried using a commit which was
the same date as the cdmd -> ddmd switch but that didn't work.


That's the only way I know to do it, it should work.

Re: Vision 2016 H1

[tcak via Digitalmars-d]

On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
In case you missed it from the announce forum: 
http://wiki.dlang.org/Vision/2016H1 -- Andrei


Is there a list or a proper place to put the list of 
desired/asked/necessary tools together with their purpose?

Re: Collapsing n-dimensional array to linear (1 dimensional)

[Solomon E via Digitalmars-d-learn]

On Saturday, 23 January 2016 at 07:57:55 UTC, Ali Çehreli wrote:


auto collapse(R)(R r)
if (isArray!R) {
return r.joiner.collapse.joiner;
}

auto collapse(R)(R r)
if (!isArray!R) {
return r;
}



Ali, that code only passed the one test it had for collapsing a 
three level array. It wouldn't collapse arrays of other numbers 
of levels. It wasn't recursing as appeared to be intended.


Is the following code better D? (I don't know because I'm still 
learning D, so I'd like to be corrected if the comments in my 
code are inaccurate or misleading.)


(See https://issues.dlang.org/show_bug.cgi?id=12062 for where I 
got the idea that `flatten` should be defined to mutate by 
reference. A comment there suggests to use 
std.experimental.ndslice and byElement for that, but ndlslice 
doesn't seem to be in the library anymore.)



import std.stdio;
import std.range;
import std.algorithm;
import std.traits;

/** `collapse` returns an array that can be type inferred
 *  and can be cast to [] without effect
 */

auto collapse(R)(R r)
if (isArray!(ElementType!R)) {
return r.joiner.array.collapse;
}

auto collapse(R)(R r)
if (!isArray!(ElementType!R)) {
return r;
}

/** `flatten` returns a range Result that can modify the original 
by ref

 * and .flatten.array is equivalent to .collapse
 */

auto flatten(R)(R r)
if (isIterable!R && isIterable!(ElementType!R)) {
return r.joiner.flatten;
}

auto flatten(R)(R r)
if (!(isIterable!R && isIterable!(ElementType!R))) {
return r;
}

unittest {
auto r1 = 3.iota.array;
auto r2 = 3.iota.map!(i => iota(3 * i, 3 * i + 
3).array).array;

assert(r2 == [[0,1,2],[3,4,5],[6,7,8]]);
auto r3 = 3.iota
.map!(i => iota(3 * i, 3 * i + 3)
.map!(j => iota(3 * j, 3 * j + 3)
.array)
.array)
.array;
auto r4 = 3.iota
.map!(i => iota(3 * i, 3 * i + 3)
.map!(j => iota(3 * j, 3 * j + 3)
.map!(j => iota(3 * j, 3 * j + 3)
.array)
.array)
.array)
.array;
auto r5 = 3.iota
.map!(i => iota(3 * i, 3 * i + 3)
.map!(j => iota(3 * j, 3 * j + 3)
.map!(j => iota(3 * j, 3 * j + 3)
.map!(j => iota(3 * j, 3 * j 
+ 3)

.array)
.array)
.array)
.array)
.array;

writeln("\nOriginal 1 level:\n", r1);
writeln("Collapsed:\n", r1.collapse);

writeln("\nOriginal 2 level:\n", r2);
writeln("Collapsed:\n", r2.collapse);

writeln("\nOriginal 3 level:\n", r3);
writeln("Collapsed:\n", r3.collapse);

writeln("\nOriginal 4 level:\n", r4);
writeln("Collapsed:\n", r4.collapse);

writeln("\nOriginal 5 level:\n", r5);
writeln("Collapsed:\n", r5.collapse);

// equality (collapse is eager and iota is lazy)
assert(r1.collapse.equal(iota(3)));
assert(r2.collapse.equal(iota(9)));
assert(r3.collapse.equal(iota(27)));
assert(r4.collapse.equal(iota(81)));
assert(r5.collapse.equal(iota(243)));

// value equality
assert(r1.collapse == iota(3).array);
assert(r2.collapse == iota(9).array);
assert(r3.collapse == iota(27).array);
assert(r4.collapse == iota(81).array);
assert(r5.collapse == iota(243).array);

// cast is allowed and does not affect the result
assert(cast(int[]) r1.collapse == iota(3).array);
assert(cast(int[]) r2.collapse == iota(9).array);
assert(cast(int[]) r3.collapse == iota(27).array);
assert(cast(int[]) r4.collapse == iota(81).array);
assert(cast(int[]) r5.collapse == iota(243).array);

// type inference
auto ar1 = r1.collapse;
assert(ar1 == iota(3).array);
auto ar2 = r2.collapse;
assert(ar2 == iota(9).array);
auto ar3 = r3.collapse;
assert(ar3 == iota(27).array);
auto ar4 = r4.collapse;
assert(ar4 == iota(81).array);
auto ar5 = r5.collapse;
assert(ar5 == iota(243).array);

// lazy equality
assert(r1.flatten.equal(iota(3)));
assert(r2.flatten.equal(iota(9)));
assert(r3.flatten.equal(iota(27)));
assert(r4.flatten.equal(iota(81)));
assert(r5.flatten.equal(iota(243)));

// equivalence between .flatten.array and .collapse
assert(r1.flatten.array == ar1);
assert(r2.flatten.array == ar2);
assert(r3.flatten.array == ar3);
assert(r4.flatten.array == ar4);
assert(r5.flatten.array == ar5);

// mutation by reference through a flatten
foreach (ref x; r3.flatten) {
x++;
}
writeln("r3 scalar incremented ", r3);
auto r3i = iota(1, 4)
.map!(i => iota(3 * i - 2, 3 * i + 1)
.map!(j => iota(3 * j - 2, 3 * j + 1)
 

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 3:37 PM, Andrei Alexandrescu wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


There is a couple of things I want on there.

1. scope to be fixed and fully implemented
   (I'll bring some use cases to the table)
2. @assumenogc or something similar.
   That way IAllocator can be @nogc. Which to me is a requirement 
before it is out of experimental.


Number 1 is the most important for me. Otherwise there will be no 
review/PR for image library this year.

Re: When is the Win API supported?

[Rikki Cattermole via Digitalmars-d]

On 25/01/16 2:46 PM, Igor wrote:

When will the proper Win API be included in D? About how long(months,
years?)? Does it support seamless narrow and wide characters?

I am not referring to the defunct win32 support already included.


You mean the MingW based bindings that is in 2.070?
https://github.com/D-Programming-Language/druntime/tree/v2.070.0-b2/src/core/sys/windows

The only issue is for -m32 with import libs.

Vision 2016 H1

[Andrei Alexandrescu via Digitalmars-d]

In case you missed it from the announce forum: 
http://wiki.dlang.org/Vision/2016H1 -- Andrei

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 4:13 PM, Andrei Alexandrescu wrote:

On 01/24/2016 10:07 PM, Rikki Cattermole wrote:


1. scope to be fixed and fully implemented
(I'll bring some use cases to the table)
2. @assumenogc or something similar.
That way IAllocator can be @nogc. Which to me is a requirement
before it is out of experimental.


Both are under the larger headline "Memory Management." -- Andrei


Okay, I like specifics since then you can tick it off for next round ;)

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 01/24/2016 10:07 PM, Rikki Cattermole wrote:


1. scope to be fixed and fully implemented
(I'll bring some use cases to the table)
2. @assumenogc or something similar.
That way IAllocator can be @nogc. Which to me is a requirement
before it is out of experimental.


Both are under the larger headline "Memory Management." -- Andrei

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


Something went wrong here:

We fell short of our 2000 pull requests goal in H2 2015. We 
have had only 1 1378 pull requests.


In addition to the extraneous "1", the link is bad: "No results 
matched your search."

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of 
created. That may provide the core team a subconsious incentive 
to look at long pending PRs and hit a good cycle.


For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, crossplatform). 
A good official supported GUI library will attract many people.

When is the Win API supported?

[Igor via Digitalmars-d]

When will the proper Win API be included in D? About how 
long(months, years?)? Does it support seamless narrow and wide 
characters?


I am not referring to the defunct win32 support already included.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 4:21 PM, Puming wrote:

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of
created. That may provide the core team a subconsious incentive to look
at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both) there 
is no way a GUI toolkit is going in. And from what I know there will be 
a LOT of work to update it.

Downtime of gdc ftp, bugzilla, site, et. al.

[Iain Buclaw via Digitalmars-d]

Hi,

I will be doing some long overdue maintenance to all services 
hosted on gdcproject.org.  This is starting with a backup of all 
data / configuration, followed by a complete rebuild.


First service that I'll try to bring up in a timely manner is the 
FTP site, though that largely depends on upload time (there's 
about 5GB worth to rsync over).


Apologies for any inconvenience.
Iain.

What are the real GUI toolkits for D?

[nbro via Digitalmars-d]

Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit. Anyway, a serious programming language 
nowadays should have a lot more support in that area. I have not 
tried GtkD yet, but it seems the most promising. Many projects 
have started to create a GUI toolkit (or wrapper), but now they 
are abandoned. Are there any plans to really support the 
development of standard GUI toolkit?

Re: What's the real support that D offers for web development?

[nbro via Digitalmars-d]

On Sunday, 24 January 2016 at 12:27:57 UTC, WebFreak001 wrote:

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:
I have heard about vibe.d, but I am not convinced. I think 
that many people do not start using D because it lacks of many 
serious tools for real life applications development.


vibe.d is a really good one. In my opinion its basically a 
replacement of express for nodejs, just for D. Also considering 
that you could use any C library in D you could use anything 
which is written in C which gives much more possibilities.


Ok, but I would like to see concrete real world examples created 
with vide.d. Are there any?

Re: [dlang.org] Let's talk about the logo

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 23 January 2016 at 18:58:21 UTC, Artur Skawina wrote:

On 01/23/16 02:11, ronaldmc via Digitalmars-d wrote:
Linux development works because Linus is right often enough. It 
really is that simple.


But I also think Linus weighs different solutions (and 
implementations and performance) before landing on a decision? So 
the "democratic" aspect is:


1. Being able to put forth different implementations for 
evaluation.


2. Being able to fork the project (SELinux?) and merge back the 
proven solutions.


Anyway, it is important that one person feel responsible for 
every single aspect of the design and is able to defend status 
quo of the whole.


Otherwise you get a blame game instead: "Oh, I didn't really 
agree with 50% of the features we added so I don't really know 
why they are there or if they should be there. You know, I told 
you guys it was a bad idea to have those features, so I think the 
ones that voted for them should fix it."

Re: Templates, templates, templates...

[anonymous via Digitalmars-d-learn]

On 24.01.2016 10:02, Voitech wrote:

I added base class for Rule -> BaseRule. But this class is just a shell
without implementation.
Is there any way to avoid this ?


What's the problem with BaseRule not having any implementation? When the 
different Rule instantiations don't have any common operations that can 
be put there, then BaseRule's purpose is only to be a common supertype.

Re: vibe.d 0.7.27-beta.1

[Sönke Ludwig via Digitalmars-d-announce]

Am 24.01.2016 um 14:14 schrieb Robert M. Münch:

On 2016-01-24 12:49:25 +, Snke Ludwig said:


I didn't build libevent for win64 so far and I'd rather not want to
invest that time. Instead, I'd recommend to just use the "win32"
configuration of vibe-d(:core) on that platform.


Just to be sure I get it. On Win32 I could use "libevent" or "win32
native", right? So, the libevent is not mandatory for Windows at all?


Correct.


 Probably the "libevent" configuration should just be disabled on
win64...


If it's not necessary I highly vote for this. Keep things simple and
streamlined as much as possible. The less dependencies the better.



Okay, I'll do that for the upcoming release! I know of nobody who has 
compiled libevent for Win64 themselves, so it doesn't make much sense to 
offer the configuration.

Re: Define "createXXX" functions for the constructors of class XXX

[Johan Engelen via Digitalmars-d-learn]

Thanks for the rapid explanations and code!
Such a great forum :-)

Much obliged,
  Johan

Re: DIP 88: Simple form of named parameters

[default0 via Digitalmars-d]

On Sunday, 24 January 2016 at 11:20:20 UTC, Gary Willoughby wrote:

Please, no more new syntax!

This can be done using templates and Flag is not an ugly hack!


Why no more new syntax? I agree that keeping the language simple 
is a good idea, but new syntax isn't usually hard to learn, 
especially if it hits the sweet spot between being different 
enough to easily tell that it means something special/new and 
being close enough to the rest of the syntax to not feel alien.


Also Flag seems like quite the waste of linespace. In addition to 
the name of the parameter I lose 7 characters (Flag!""). Named 
arguments would only use up 2 (: ) or 3 ( = ) characters.
Plus, being a library solution, at first it makes you wonder if 
there is something special going on with Flag (cuz you know, 
types usually have associated behaviour), instead of being purely 
for documentation purposes.

Totally qualifies as a hack to me.

Re: What's the real support that D offers for web development?

[WebFreak001 via Digitalmars-d]

On Sunday, 24 January 2016 at 12:32:16 UTC, nbro wrote:
Ok, but I would like to see concrete real world examples 
created with vide.d. Are there any?


Its really difficult to find projects using vibe.d randomly. I 
have seen a few sites where it said in the footer that the 
website is powered by D, but I cant remember those.


If you want to see which notable companies use D for their 
projects in general (not only vibe.d): 
http://wiki.dlang.org/Current_D_Use

Output range for file?

[Tofu Ninja via Digitalmars-d-learn]

I tried looking for this in phobos but cant seem to find it which 
is really annoying. For my uses this works:


struct fileOutRange
{
File f;
void put(ubyte[] a)
{
f.rawWrite(a);
}
}

But was just wondering if there was a real output range for files 
somewhere in phobos that I just cant seem to find.

Re: New D book available for pre-order: D Web Development

[notna via Digitalmars-d-announce]

On Thursday, 17 December 2015 at 08:08:26 UTC, Kai Nacke wrote:
Hi Kai.

Any news? Just some days left until "January 2016" is over ;)

Regards
Anton


On Monday, 30 November 2015 at 03:36:29 UTC, Nick B wrote:

On Sunday, 29 November 2015 at 18:24:38 UTC, Kai Nacke wrote:

On Wednesday, 25 November 2015 at 04:35:47 UTC, Nick_B wrote:




Hi Nick!

Yes, the book will be available in hardcopy.

Proposed publication date is January 2016.

Regards,
Kai



Kai - Are you saying that the hardcopy will be available Jan 
2016 ?


Nick


Yes, it should. I finished all my rework. The book is now in 
the production phase...


Regards,
Kai

Re: [dlang.org] Let's talk about the logo

[Ola Fosheim Grøstad via Digitalmars-d]

On Saturday, 23 January 2016 at 00:30:17 UTC, H. S. Teoh wrote:
got this strange notion from.  Walter is the one who invented 
this language, and he has been generous enough to let the rest 
of us participate in its development.


Yes, I agree with this. If anything, bringing too much democracy 
into a design process makes things bloated and inconsistent. 
Walter has probably been too accepting of suggestions to new 
features in the past. But if someone steps up as a committed 
graphic designer it would be a good idea to give that person free 
hands. That's very motivating.


Meritocracy is not a horrible concept though. Implementing bad 
ideas and refusing good ideas based on who suggested it is just 
dumb. You need a lead designer that plots out what needs to be 
done and brings it all together as a whole.


That said, it would be downright silly to not accept the two 
bottom logos ;-).

Re: vibe.d 0.7.27-beta.1

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

On 2016-01-24 12:49:25 +, Snke Ludwig said:

I didn't build libevent for win64 so far and I'd rather not want to 
invest that time. Instead, I'd recommend to just use the "win32" 
configuration of vibe-d(:core) on that platform.


Just to be sure I get it. On Win32 I could use "libevent" or "win32 
native", right? So, the libevent is not mandatory for Windows at all?



 Probably the "libevent" configuration should just be disabled on win64...


If it's not necessary I highly vote for this. Keep things simple and 
streamlined as much as possible. The less dependencies the better.


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

Re: DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-24 14:24, Michel Fortin wrote:


On further thought, how do you make templates with specialization take
named arguments?

 template TFoo(T){ ... } // #1
 template TFoo(T : T[])  { ... } // #2
 template TFoo(T : char) { ... } // #3

My guess would be this:

 template TFoo(T:){ ... } // #1
 template TFoo(T: : T[])  { ... } // #2
 template TFoo(T: : char) { ... } // #3

... but it makes the declaration a bit strange.


Yes. Rule 7 covers that. There's also an example showing the syntax, 
search for "Template specialization with named parameter". Yes, it does 
look a bit strange.


--
/Jacob Carlborg

Re: DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-24 14:16, Michel Fortin wrote:


Have you considered supporting separate variable names? Like this:

 void login(string username: name, string password:) {
 writeln(name ~ ": " ~ password);
 }


No, not really.

--
/Jacob Carlborg

Re: What's the real support that D offers for web development?

[Sönke Ludwig via Digitalmars-d]

Am 24.01.2016 um 14:57 schrieb krzaq:

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:

I was wondering if D is a good language for web development. Which
serious with an active community web frameworks are there?

I have heard about vibe.d, but I am not convinced. I think that many
people do not start using D because it lacks of many serious tools for
real life applications development.


I'm afraid not, not for anything serious at least. The documentation is
okay, but not great; greatly lacking examples.


Have you seen the example projects?
https://github.com/rejectedsoftware/vibe.d/tree/master/examples


There is no built-in
support for any real database engines and if you try to use something
not built with vibe.d's fiber architecture in mind (even things from the
standard library, like std.process) you're in for a world of random locks.


I don't know which database engines are "real", but there are fully 
vibe.d compatible drivers for at least MySQL, Postgres and Cassandra. 
Built-in solutions are requested from time to time, but the plan is 
actually to go into the opposite direction and make the MongoDB and 
Redis clients separate libraries.


There are several means to integrate traditional I/O code:
http://vibed.org/api/vibe.core.core/createFileDescriptorEvent
http://vibed.org/api/vibe.stream.stdio/
https://gist.github.com/s-ludwig/8434299

But this is a general issue with asynchronous I/O. You either need to 
use it throughout the application, or offload blocking I/O into a 
separate thread. Whether those difficulties are worth the trade-off in 
comparison to the performance gains is of course a decision you have to 
make personally/per project.



I don't have pretty much any experience in webdev, but I tried RoR,
node.js and vibe.d. Let me say, the experience was not in the vibe.d's
favour.

Re: alias template parameter

[Marc Schütz via Digitalmars-d-learn]

On Friday, 21 June 2013 at 14:08:43 UTC, Sergei Nosov wrote:

If I have a function
auto apply(alias fun, T...)(T args)
{
return fun(args);
}

And then I have
int y = 2;
apply!(x => y)(1);

How in the world does this work? Is the context address known 
at compile-time?


No, but because lambdas are always unique, there will always be a 
dedicated template instance for every time you do this. The 
compiler will then hard-wire that instance to make it able to 
access the context pointer. By the way, you can also pass local 
variables by alias, in which case the same will happen. I guess 
it does so by passing the offset of the variable in the current 
stack frame (unless it's inlined and optimized, of course), but I 
don't know the details. I guess it's up to the compiler.

Re: First project: questions on how-to, and on language features

[Marc Schütz via Digitalmars-d-learn]

On Sunday, 24 January 2016 at 06:07:13 UTC, Alex Vincent wrote:
(1) It's not clear how to specify certain parts of a module or 
library as non-exportable.  Is that possible?  Is it desirable?

 (It's not that important, yet, but still...)


Yes, definitely. By default symbols in a module are `public`, but 
you can mark them as `private`. These aren't accesible from other 
modules:


module test;

void foo() { }// public, because there's no annotation
private bar() { } // private
void bar2() { }   // public again

private:  // everything from here on is private
void bla() { }
void blubb() { }



(2) In the unittest code, I have a block that I want to rewrite 
using assertThrown, but I can't figure out from either the book 
or the website the correct usage.  What's the right way to 
specify a StringException with a particular message I expect to 
receive?


Here's the relevant documentation:
https://dlang.org/phobos/std_exception.html#.assertThrown
https://dlang.org/phobos/std_exception.html#.collectExceptionMsg

`assertThrown()` doesn't allow to check the message directly, it 
can only check whether a particular type of exception has been 
thrown:


assertThrown!StringException(throw new 
StringException("test"));


Instead, you can use `collectExceptionMsg()` to check both the 
message and the exception type:


assert(
collectExceptionMsg!StringException(throw ...) == "test"
);



(4) How should the scope(exit) and scope(failure) guard 
statements intermix with preconditions and postconditions?


Pre- and postconditions are supposed to run before you enter the 
function, or after you left it, respectively. Therefore, and 
scope() blocks in the function body would already have completed 
when the postcondition is entered. OTOH, scope() blocks only run 
if control flow has passed through them. In a precondition, this 
hasn't happened yet, and therefore they will not run.


If you mean whether you can use scope() blocks in pre- and 
postconditions, yes, you can. The will then run when you leave 
the pre- and postcondition. But usually, pre- and postconditions 
only consist of very little code that's not supposed to do any 
serious work, so they are less likely to be used there.


Or, looking at it from a different angle: A scope() block only 
runs at the end of the lexical scope / block it appears in. Pre- 
and postconditions are not part of the function body, or vice 
versa. Therefore, see above.




(5) My append() function has a postcondition that currently 
depends on debug-only members of the class being set in the 
precondition.  This seems artificial - not the part about 
setting these variables in the precondition, but having the 
variables defined on the class to begin with.  If they were 
defined only for the lifetime of the function's execution, 
starting in the precondition, this would be more natural.  Is 
there a Right Way to define function-only debug variables for 
use in postconditions?  If not, would this be a valid use-case 
to consider amending the language specification to clarify?


I'm not an expert in contract programming, but as I see it, your 
precondition doesn't actually check anything, you're kinda 
abusing them as preparation for your postcondition. That's likely 
not the way it's supposed to be. I see what you're trying to 
achieve, and I believe it's legitimate to check for... You could 
either just move the assert()s into the function body just before 
the end, where you have access to the local variables (but you 
could easily miss an early return), or put them into a 
scope(exit) block (but then you could accidentally check it too 
early). Your best bet here is probably to check it in a unittest, 
although they are for a slightly different purpose, strictly 
speaking.

Re: What's the real support that D offers for web development?

[WebFreak001 via Digitalmars-d]

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:
I have heard about vibe.d, but I am not convinced. I think that 
many people do not start using D because it lacks of many 
serious tools for real life applications development.


vibe.d is a really good one. In my opinion its basically a 
replacement of express for nodejs, just for D. Also considering 
that you could use any C library in D you could use anything 
which is written in C which gives much more possibilities.

very simple pure CPU raymarching demo

[ketmar via Digitalmars-d-announce]

the following[1] is the demo of pure CPU implementation of the 
famous "raymarching" algorithm[2]. of course, doing that in GLSL 
shader will be many times faster (10x? 20x? dunno), but i'm too 
lazy to port the necessary gl headers (and don't want to use 
derelict for some random reason ;-), so i did it on CPU.


it's basically the fragment shader code, executing on CPU instead 
of GPU.


of course, one can use more threads to render image parts, but 
i'm too lazy to implement that (let's say that i left this as an 
excercise for a reader; i know you all love such "excercises").


you will need Adam's simpledisplay.d and color.d from here[3].

no OpenGL required.


[1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd.d
[2] 
http://iquilezles.org/www/articles/raymarchingdf/raymarchingdf.htm

[3] https://github.com/adamdruppe/arsd

Re: DIP 88: Simple form of named parameters

[Michel Fortin via Digitalmars-d]

On 2016-01-23 14:19:03 +, Jacob Carlborg  said:


This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


On further thought, how do you make templates with specialization take 
named arguments?


template TFoo(T){ ... } // #1
template TFoo(T : T[])  { ... } // #2
template TFoo(T : char) { ... } // #3

My guess would be this:

template TFoo(T:){ ... } // #1
template TFoo(T: : T[])  { ... } // #2
template TFoo(T: : char) { ... } // #3

... but it makes the declaration a bit strange.

--
Michel Fortin
http://michelf.ca

Re: What's the real support that D offers for web development?

[karabuta via Digitalmars-d]

On Sunday, 24 January 2016 at 13:57:35 UTC, krzaq wrote:

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:

[...]


I'm afraid not, not for anything serious at least. The 
documentation is okay, but not great; greatly lacking examples. 
There is no built-in support for any real database engines and 
if you try to use something not built with vibe.d's fiber 
architecture in mind (even things from the standard library, 
like std.process) you're in for a world of random locks.


I don't have pretty much any experience in webdev, but I tried 
RoR, node.js and vibe.d. Let me say, the experience was not in 
the vibe.d's favour.


What examples do you want, please?

Re: very simple pure CPU raymarching demo

[ketmar via Digitalmars-d-announce]

ok, just4fun, mulththreaded renderer[1]. set ThreadCount to 
number of your CPU cores to get some speedup.


note: this is not how `std.concurrency` should be used! please, 
don't do wroker queues as i did!


[1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd_x4.d

Re: Dub needs some additions

[Gary Willoughby via Digitalmars-d]

On Saturday, 23 January 2016 at 20:24:05 UTC, Igor wrote:
Some simple extensions to dub are required for proper windows 
support:


1. The Ability to generate full build selections for Visual D. 
I only get Win32 when using `dub generate VisualD`. Win64 
support should be added, along with alternate compiler support. 
(GDC and LDC)


2. The ability to refresh a project by adding new dependencies 
and files to the previously generate Visual D project. It 
should retain modified settings of the project file. I'm 
thinking of something like `dub refresh VisualD` would work.


The current generate settings are just child's toys without the 
ability to retain and update project info.


Thank You.


Dub forums:

http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/

Re: DIP 88: Simple form of named parameters

[Gary Willoughby via Digitalmars-d]

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg 
wrote:

This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88


"A new syntax is added to be used when declaring a function that 
should be callable with named parameters:"


Please, no more new syntax!

This can be done using templates and Flag is not an ugly hack!

Re: DIP 88: Simple form of named parameters

[default0 via Digitalmars-d]

On Sunday, 24 January 2016 at 10:40:10 UTC, Jonathan M Davis 
wrote:

On Sunday, 24 January 2016 at 10:14:53 UTC, default0 wrote:

Anyone who wrote a function like that is just plain writing bad 
code. With that many parameters, they should be creating a 
struct to hold the values. Named arguments really only seem to 
help in cases where functions are badly designed. I don't want 
to use them in my code, and I don't want to have to deal with 
them in other people's code. And as a library writer, I don't 
want to have to argue with anyone about whether the names that 
I picked for my parameters were good or not. We already get way 
too much bikeshedding over function names as it is without 
adding parameter names into the mix.


- Jonathan M Davis


I agree that functions like that are badly designed. However they 
exist and you can't always change them.
That said, if there'd be traits for parameter names you can 
probably automate the creation of a decent struct-wrapper, making 
this a non-issue for D (you could not do that in C#, so writing 
wrappers would be a huge pain there).
Regarding the bikeshedding: I honestly don't think this increases 
the amount of bikeshedding happening. There'll always be 
bikeshedding anyways, independent of if you give many 
opportunities for it or not.


Thinking further about this, though, and being the inexperienced 
D user I am, I assume you use struct wrappers sort of like this?

ArgStruct s;
s.param1 = 12;
M(s);

If yes, consider that a named argument alternative would be far 
less noisy:

M(param1: 12);

If my code above is far more verbose than what you'd usually do 
(ie comparable to the succinctness of the named argument), can 
you please give an example?

Re: DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-23 19:27, Chris Wright wrote:


One huge usecase for this is methods with many optional parameters.
You've missed that. For instance, I wrote a method with six optional
parameters recently. It's unusable without named parameters. I switched
to a parameter struct, but it's still not that great.


I did not miss that. I deliberately chose to not support changing the 
order of the arguments.



I'd also add that this proposal doesn't affect UFCS.


How would it affect UFCS?


What about overloading based on parameter names? The proposal doesn't
even mention the idea, so there's no guessing whether you considered and
rejected it or just didn't consider it.


The DIP mentions that no change is required for function overloading. 
But I added an explicitly rule about that.



I'll note that parameter names are already part of documentation, and
they're already the only parameter documentation you're guaranteed to
have.


Currently it's possible to change a parameter name without the call site 
needing any change. Documentation has nothing to do with that.



The Dart devs decided that named parameters must be explicitly set out as
named, and they cited the same reason. The C# devs, on the other hand,
made every parameter a named parameter. I haven't heard of any explosions
in C# land, and it's been five years.

Your proposal is closer to C#'s version than Dart's. In Dart, a named
parameter cannot be called positionally:

   foo({a, b}) {}
   main() {
 // This works:
 foo(b: 1, a: 2);

 // Error: 0 positional arguments expected, 2 found
 foo(2, 1);
   }

In C#, a named parameter is only about the call site and has nothing to
do with the function being called. A function you wrote for C# 1.1 and
never modified can be called with named parameters in C# 4.0. You can
still call these functions with positional-style parameters.


Changing the order when using the named parameter syntax is not legal:


Why not?

Let's look at languages with named parameters. Python: reorderable. C#:
reorderable. Dart: reorderable. Scala: reorderable. Ada: reorderable.

Given this trend, people will be confused if they can't reorder named
parameters. The main benefit of not letting people reorder things is
reducing the amount of work *you* need to do when creating this DIP (and
the amount others need to do when implementing it).


No. The only reason why that is not allowed is to have a greater chance 
of the DIP being accepted. The language would be even more complicated 
if it was possible to reorder the arguments. It's a benefit for the 
users if the language is simpler.



Document how it's supposed to handle optional parameters


It's already documented.

--
/Jacob Carlborg

Re: vibe.d 0.7.27-beta.1

[Sönke Ludwig via Digitalmars-d-announce]

Am 23.01.2016 um 16:42 schrieb Robert M. Münch:

Error: Error reading file
'C:\Users\robby\AppData\Roaming\dub\packages\vibe-d-0.7.27-beta.1\lib\win-amd64\event2.lib'


I didn't build libevent for win64 so far and I'd rather not want to 
invest that time. Instead, I'd recommend to just use the "win32" 
configuration of vibe-d(:core) on that platform. Probably the 
"libevent" configuration should just be disabled on win64...

Re: What's the real support that D offers for web development?

[Sönke Ludwig via Digitalmars-d]

Am 24.01.2016 um 13:32 schrieb nbro:

On Sunday, 24 January 2016 at 12:27:57 UTC, WebFreak001 wrote:

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:

I have heard about vibe.d, but I am not convinced. I think that many
people do not start using D because it lacks of many serious tools
for real life applications development.


vibe.d is a really good one. In my opinion its basically a replacement
of express for nodejs, just for D. Also considering that you could use
any C library in D you could use anything which is written in C which
gives much more possibilities.


Ok, but I would like to see concrete real world examples created with
vide.d. Are there any?


I still need to collect a proper list of sites some day, but there are 
some examples in the D eco system:


https://vibed.org
https://forum.rejectedsoftware.com/
https://code.dlang.org/
https://sdlang.org/

You could do a search for "vibe.d" on shodan to get a (very incomplete 
due to proxies and missing forward DNS host names) list of public 
servers running vibe.d.

Re: What's the real support that D offers for web development?

[krzaq via Digitalmars-d]

On Sunday, 24 January 2016 at 12:20:44 UTC, nbro wrote:
I was wondering if D is a good language for web development. 
Which serious with an active community web frameworks are there?


I have heard about vibe.d, but I am not convinced. I think that 
many people do not start using D because it lacks of many 
serious tools for real life applications development.


I'm afraid not, not for anything serious at least. The 
documentation is okay, but not great; greatly lacking examples. 
There is no built-in support for any real database engines and if 
you try to use something not built with vibe.d's fiber 
architecture in mind (even things from the standard library, like 
std.process) you're in for a world of random locks.


I don't have pretty much any experience in webdev, but I tried 
RoR, node.js and vibe.d. Let me say, the experience was not in 
the vibe.d's favour.

Re: DIP 88: Simple form of named parameters

[Andrej Mitrovic via Digitalmars-d]

On 1/24/16, Jonathan M Davis via Digitalmars-d
 wrote:
> I would strongly argue that anyone who feels the need for named
> parameters should rethink how they're designing their functions.

Another example where they become useful is with functions that take
source and destination parameters. E.g.:

void copy ( Buffer src, Buffer tgt ) { }

vs

void copy ( Buffer tgt, Buffer src ) { }

With regard to param names being part of the API I think that:

- Parameter names very rarely change
- It's the responsibility of the client code authors to fix any code
breakage due to parameter renaming

I think the best thing we can do before completely dismissing this
idea is to look into the experience of other programming communities
(like Python) and try to weigh the pros vs the cons.

Re: Choosing D over C++, Go, Rust, Swift

[Dibyendu Majumdar via Digitalmars-d]

On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar 
wrote:
I wrote recently that I am looking at an alternative to C++ for 
a project currently being coded in C++. I am pleased to say 
based on preliminary investigations I have chosen D over Go, 
Rust, and Swift.


1. D appears to give me all the power of C++ - and in 
particular even greater power with templates.


2. D code is cleaner, more traditional (Java and C like), and 
easier to read and understand than some of the alternatives. Go 
is simpler of course and also easy to follow - but that is 
because it is a small language. I dislike the new syntax of 
Rust as it seems gratuitously different and (in my view) hard 
to read.


3. D gives me all the low level control while at the same time 
giving me the ability to write code at a higher level. C++ is 
similar but the other languages are all restrictive in some way 
or other.




Hi - just to give you an update. After trying to get some simple 
tests working for the past few days I have concluded that while D 
is the best choice for my project (after C++) - D's 
implementation and tooling is not mature enough yet for me to 
spend effort on a port. So I will defer the move to D to a future 
time - but my intention is to do other work in D related to my 
OpenSource projects around Lua.


I really want to use D as a better C / C++ so am looking forward 
to library developments that better support a style of 
programming that relies less on GC. Its not that I don't like GC 
- but I feel that the reasons for my using a language like D or 
C++ is control - else I would use Java or Swift or Go.


Regards
Dibyendu

Re: DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-24 12:20, Gary Willoughby wrote:


This can be done using templates and Flag is not an ugly hack!


It's one of the most ugly things I've seen in D.

--
/Jacob Carlborg

Re: DIP 88: Simple form of named parameters

[Jacob Carlborg via Digitalmars-d]

On 2016-01-24 11:14, default0 wrote:


As for this DIP I don't know - it seems to be well-thought-out, albeit
with a focus on ease of implementation rather than usefulness for a
language user, so I don't really have a conclusive opinion on that.


It's focused on having a realistic chance of being accepted.

--
/Jacob Carlborg

What's the real support that D offers for web development?

[nbro via Digitalmars-d]

I was wondering if D is a good language for web development. 
Which serious with an active community web frameworks are there?


I have heard about vibe.d, but I am not convinced. I think that 
many people do not start using D because it lacks of many serious 
tools for real life applications development.

Re: DIP 88: Simple form of named parameters

[Michel Fortin via Digitalmars-d]

On 2016-01-23 14:19:03 +, Jacob Carlborg  said:


This is mostly to prevent ugly hacks like Flag [1].

http://wiki.dlang.org/DIP88

[1] https://dlang.org/phobos/std_typecons.html#.Flag


Interesting.

This is somewhat similar to an experiment of mine from 5 years ago. My 
implementation was a bit of a hack, but my intent was to have a proof 
of concept done quickly. All arguments were considered optionally named 
in this experiment (there was no syntax to enable this in the function 
prototype). Also it didn't extend to templates arguments.


You can my discussion with Walter about it here:
https://github.com/michelf/dmd/commit/673bae4982ff18a3d216bc1578f50d40f4d26d7a

Mixing reordering with overloading can become quite complicated. It's 
good that you leave that out at first. Adding reordering should be left 
as a separate task for later, if desired. Small steps.


Have you considered supporting separate variable names? Like this:

void login(string username: name, string password:) {
writeln(name ~ ": " ~ password);
}

where an identifier following the colon, if present, would be the name 
of the variable inside the function. That way you can use a shorter 
variable when it makes sense to do so. Or change the variable name 
without affecting the API.


--
Michel Fortin
http://michelf.ca

Re: Choosing D over C++, Go, Rust, Swift

[maik klein via Digitalmars-d]

On Sunday, 24 January 2016 at 12:04:58 UTC, Dibyendu Majumdar 
wrote:
On Thursday, 14 January 2016 at 13:47:39 UTC, Dibyendu Majumdar 
wrote:
I wrote recently that I am looking at an alternative to C++ 
for a project currently being coded in C++. I am pleased to 
say based on preliminary investigations I have chosen D over 
Go, Rust, and Swift.


1. D appears to give me all the power of C++ - and in 
particular even greater power with templates.


2. D code is cleaner, more traditional (Java and C like), and 
easier to read and understand than some of the alternatives. 
Go is simpler of course and also easy to follow - but that is 
because it is a small language. I dislike the new syntax of 
Rust as it seems gratuitously different and (in my view) hard 
to read.


3. D gives me all the low level control while at the same time 
giving me the ability to write code at a higher level. C++ is 
similar but the other languages are all restrictive in some 
way or other.




Hi - just to give you an update. After trying to get some 
simple tests working for the past few days I have concluded 
that while D is the best choice for my project (after C++) - 
D's implementation and tooling is not mature enough yet for me 
to spend effort on a port. So I will defer the move to D to a 
future time - but my intention is to do other work in D related 
to my OpenSource projects around Lua.


I really want to use D as a better C / C++ so am looking 
forward to library developments that better support a style of 
programming that relies less on GC. Its not that I don't like 
GC - but I feel that the reasons for my using a language like D 
or C++ is control - else I would use Java or Swift or Go.


Regards
Dibyendu


I am in a similar boat, I don't need the GC at all and there is 
not much stuff in the std to support a programming style like in 
C++. Also I already run into a couple of bugs in the std which I 
am currently trying to fix or work around. It is quite annoying.


But it is still the best bet if you want to do any 
metaprogramming, I think I have tried all statically compiled 
languages so far and nothing really comes close to what C++ can 
do. But D even improves on C++'s metaprogramming and it compiles 
so much faster.


Actually I personally came to the conclusion that C++ is kinda 
useless for metaprogramming because the compile times will 
explode very quickly.


A small entity component system with compile time filtering that 
I have written in C++ takes around 15 seconds for a toy example. 
In D it is ~1sec and the number doesn't seem go go up at all.

Re: New D book available for pre-order: D Web Development

[Kai Nacke via Digitalmars-d-announce]

On Sunday, 24 January 2016 at 13:03:42 UTC, notna wrote:

Any news? Just some days left until "January 2016" is over ;)


I am checking the pre-final PDFs of the last chapters right now.
Publishing date will be very soon

Regards,
Kai

Re: What are the real GUI toolkits for D?

[karabuta via Digitalmars-d]

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit. Anyway, a serious programming language 
nowadays should have a lot more support in that area. I have 
not tried GtkD yet, but it seems the most promising. Many 
projects have started to create a GUI toolkit (or wrapper), but 
now they are abandoned. Are there any plans to really support 
the development of standard GUI toolkit?



Not only that, there are also;
DQML(if you want Qt's QML) https://github.com/filcuc/dqml

DlangUI(written in D for Windows, mac, Linux) 
https://github.com/buggins/dlangui


tkd(Tkinter) https://github.com/nomad-software/tkd

Awesomium (Webview) https://github.com/k3kaimu/awebview

Dude, there are no other cross platform GUIs aside these and 
(GtkD & DWT), and that is the case in every programming language 
there is today(that I know of and is matured enough). Currently 
Qt is the only one I know that works but it is written in C++ 
plus others high level stuff with binding in python.


So you either go with Windows Form for windows only, or Mac GUI 
toolkit only or GtkD which at least works with Mac and De facto 
for Linux distros. Else haha!!


If you want all D, the DlangUI is your solution at the moment. 
Check DlangIDE written with DlangUI from 
https://github.com/buggins/dlangide

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:

On 25/01/16 4:21 PM, Puming wrote:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
Alexandrescu wrote:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead 
of
created. That may provide the core team a subconsious 
incentive to look

at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide
seems a good candidate(native D, crossplatform). A good 
official

supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on 
both) there is no way a GUI toolkit is going in. And from what 
I know there will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, 
say, link in D frontpage(like visualD).

opIndex overload for slice not working...

[Enjoys Math via Digitalmars-d-learn]

class V(T) {
public:
   this() {}
   V opIndex(size_t i, size_t j) {
 writeln("Hello, foo!");
 return this;
   }
}

main() {
   auto v = new V!int();
   auto u = v[3..4];// ERROR
}

Error:
no [] operator overload for type the_module.V!int

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
Andrei


[snip]

For tooling, I suggest a look at GUI/IDEs, now that 
dlangui/dlangide seems a good candidate(native D, 
crossplatform). A good official supported GUI library will 
attract many people.


I truly doubt that. It would be truly amazing if that were to 
occur but history has proven otherwise. The sentiment was 
expressed so many times that Walter was finally moved to sanction 
DWT as the official GUI for D in 2006. Even a newsgroup was made 
for it. It's ten years later. DWT anyone?


Aurora was a recent attempt that was shelved for the sole 
author's personal reasons. Result?


Sadly, dlangui/dlangide is no different. It has one developer. If 
that individual gets discouraged, like so many others have so 
far, what becomes of it?


Until members of the community starts combining efforts and 
working together to improve the situation, it will not improve. 
You have Adam working on working on simpledisplay, Mike working 
on Derelict, Felix working on three-d, Vladimir working on 
ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and 
who knows what else is out there in the wood works. All of this 
is admirable and appreciated but imagine what would be possible 
if these minds teamed up, mapped out a graphic solution for the 
language and united efforts in implementing it!


I'm convinced that without such a deliberate effort, this 
situation will not change for years to come. Even if a particular 
library is dubbed "The One." Like I've said earlier, that was 
already done ten years ago.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Mon, 2016-01-25 at 16:49 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
> 
[…]
> That won't be happening anytime soon.
> Until we have image and windowing in Phobos (I'm working on both)
> there 
> is no way a GUI toolkit is going in. And from what I know there will
> be 
> a LOT of work to update it.

How about we have a D library infrastructure such that Phobos gets
smaller and smaller providing only absolutely necessary core things
over druntime.

If the Python, Rust, Go, etc. stories tell us anything, it is that the
days of "batteries included" distributions is long, long dead. DVCS
changes the game.

Phobos the library needs to go to be replaced by a library search and
use system. Oh we already have one, Dub.

The strategy should be "get rid of anything in Phobos that can be put
out as a separate library".
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



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

Re: opIndex overload for slice not working...

[Ali Çehreli via Digitalmars-d-learn]

On 01/24/2016 10:37 PM, Enjoys Math wrote:
> class V(T) {
> public:
> this() {}
> V opIndex(size_t i, size_t j) {
>   writeln("Hello, foo!");
>   return this;
> }
> }
>
> main() {
> auto v = new V!int();
> auto u = v[3..4];// ERROR
> }
>
> Error:
> no [] operator overload for type the_module.V!int

That usage used to be supported by opSlice. Here is my interpretation of it:


http://ddili.org/ders/d.en/operator_overloading.html#ix_operator_overloading.opSlice

However, with relatively recent changes to D, expressions like v[3..4] 
are now represented more powerfully by opIndex() templates. Expressions 
3..4 must first be passed through an opSlice() template to describe what 
it means to your type.


Usually, 3..4 can trivially be represented by a Tuple!(size_t, size_t) 
(or by a custom type):


   struct Range {
   size_t begin;
   size_t end;
   }

   Range opSlice(size_t dimension)(size_t begin, size_t end) {
   return Range(begin, end);
   }

My interpretation of this new scheme is at


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.multi-dimensional%20operator%20overloading

Here is your code with those changes:

import std.stdio;

class V(T) {
public:
   this() {}

   struct Range {
   size_t begin;
   size_t end;
   }

   // Could return a Tuple
   Range opSlice(size_t dimension)(size_t begin, size_t end) {
   return Range(begin, end);
   }

   V opIndex(A...)(A args) {
   foreach (dimension, arg; args) {
   writefln("dimension: %s, accessing %s", dimension, arg);
   }
   return this;
   }
}

void main() {
   auto v = new V!int();
   auto u = v[3..4];
}

Prints

dimension: 0, accessing Range(3, 4)

Ali

Re: Vision for the first semester of 2016

[tsbockman via Digitalmars-d-announce]

On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
The strategy should be "get rid of anything in Phobos that can 
be put

out as a separate library".


This makes no sense as a standard: since neither DMD nor druntime 
is allowed to depend upon Phobos, everything in Phobos *could* be 
put into a separate library.

[Issue 15603] New: ICE in cgxmm.c 647

[via Digitalmars-d-bugs]

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

  Issue ID: 15603
   Summary: ICE in cgxmm.c 647
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

import std.stdio;
import std.math;

void main()
{
T cfloor(T)(T x)
{
return floor(x.re)+floor(x.im)*1i;
}
(1+1i-cfloor(1+1i)).writeln; // OK
}
output: Internal error: backend/cgxmm.c 647

--

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 7:39 PM, Andrew Edwards wrote:

On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


[snip]


For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


I truly doubt that. It would be truly amazing if that were to occur but
history has proven otherwise. The sentiment was expressed so many times
that Walter was finally moved to sanction DWT as the official GUI for D
in 2006. Even a newsgroup was made for it. It's ten years later. DWT
anyone?

Aurora was a recent attempt that was shelved for the sole author's
personal reasons. Result?

Sadly, dlangui/dlangide is no different. It has one developer. If that
individual gets discouraged, like so many others have so far, what
becomes of it?

Until members of the community starts combining efforts and working
together to improve the situation, it will not improve. You have Adam
working on working on simpledisplay, Mike working on Derelict, Felix
working on three-d, Vladimir working on ae-graphics, Martin on
freeimage, Vadim on dlangui/dlangide and who knows what else is out
there in the wood works. All of this is admirable and appreciated but
imagine what would be possible if these minds teamed up, mapped out a
graphic solution for the language and united efforts in implementing it!

I'm convinced that without such a deliberate effort, this situation will
not change for years to come. Even if a particular library is dubbed
"The One." Like I've said earlier, that was already done ten years ago.


I agree.
This is why everything I'm doing right now for windowing and image 
library builds upon what has come before but in a Phobos quality way.


Unless it is in Phobos, its not good enough as a base IMO.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 7:18 PM, Puming wrote:

On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole wrote:


I want us to hold off on that as well.


I agree that we need a more solid base.


I want people to really have a go with making GUI toolkits in D
without the worry about how to do the cross platformy technical things.


Is dlangui a good start on this?


No, too much code for what the base needs.
For windowing you want it just above what the OS does in a cross 
platform abstracted way.


So no controls support or any other gruff that a GUI toolkit provides.



We just don't know what could be done yet and I'm looking forward to
finding out.


I think improving dlangide will give us many opportunities for what a
good D native GUI library needs.


No, it already has its core code. By in large what you want to innovate 
is the core code, not what a specific control does.


I'm not saying dlangui is the wrong way to go. We just don't know which 
way is right just yet and that is ok.

Re: What are the real GUI toolkits for D?

[Luis via Digitalmars-d]

On Sunday, 24 January 2016 at 12:16:09 UTC, nbro wrote:
Except for GtkD and DWT, D does not seem to be supported by a 
really nice GUI toolkit. Anyway, a serious programming language 
nowadays should have a lot more support in that area. I have 
not tried GtkD yet, but it seems the most promising. Many 
projects have started to create a GUI toolkit (or wrapper), but 
now they are abandoned. Are there any plans to really support 
the development of standard GUI toolkit?


My recommendation is that you try to use GtkD or TkD as they just 
work.
Also, there is minigui that uses Win32 NATIVE GUI and something 
similar on Linux. I don't try it, but looks more promising like 
others because  is NATIVE and not need to use a 2d game graphics 
library to work -> 
https://github.com/adamdruppe/arsd/blob/master/minigui.d

Re: opIndex overload for slice not working...

[biozic via Digitalmars-d-learn]

On Monday, 25 January 2016 at 06:37:13 UTC, Enjoys Math wrote:

class V(T) {
public:
   this() {}
   V opIndex(size_t i, size_t j) {
 writeln("Hello, foo!");
 return this;
   }
}

main() {
   auto v = new V!int();
   auto u = v[3..4];// ERROR
}

Error:
no [] operator overload for type the_module.V!int


You're mixing slicing and indexing. Use *opSlice* to support i..j 
slicing notation.


---
import std.stdio;

class V(T) {
public:
   this() {}

   V opIndex(size_t i, size_t j) {
 writeln("Indexing");
 return this;
   }

   V opSlice(size_t i, size_t j) {
 writeln("Slicing");
 return this;
   }
}

void main() {
   auto v = new V!int();
   auto w = v[3, 4]; // Indexing
   auto u = v[3..4]; // Slicing
}
---

Re: Vision 2016 H1

[Joakim via Digitalmars-d]

On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:
In case you missed it from the announce forum: 
http://wiki.dlang.org/Vision/2016H1 -- Andrei


Some comments:

- I'm not sure number of PRs is worth measuring, maybe a better 
metric would be number of devs submitting a PR, especially given 
your goal of raising participation.  If it's just a core group of 
devs submitting most of those PRs, does it matter much that they 
had more time to work on D a year ago?


- I don't think the language of military hierarchy, ie 
general/lieutenant/soldier, applies towards D.  It's more like a 
guerrilla army, think the US revolution and the Swamp Fox 
(https://en.wikipedia.org/wiki/Francis_Marion#Guerrilla_war).  
Since everybody is a volunteer, this is how it will be organized 
anyway, just pointing out that almost nobody wants to be called a 
lieutenant! :)


- It sounds like there's a fair amount of minutiae that's only 
handled by the core team right now.  I agree that formalizing 
that work into an official title or group would help get more 
people to do it, as has been done with the release manager role.  
On the other hand, every OSS project has this problem, as few 
will volunteer to take out the garbage. ;)


- Don't discount the debate on the newsgroup.  I lurked in the 
newsgroup for years before I got involved, to see what kinds of 
decisions were being made and how the process worked.  Yes, 
everybody would rather debate than chip in, but talking is 
usually a precursor for doing.


- I don't understand this section:

"This needs to be balanced with the false notion that any 
contribution must receive attention in proportion to the effort 
expended on it. 'I wrote a DIP therefore it must be worked on' 
quickly becomes 'There's no purpose in trying a DIP, nobody will 
look at it'."


Are you saying DIP and PR authors should not expect anybody to 
care about their efforts?  That would seem contrary to the goal 
of raising participation.


Perhaps a way to avoid this situation and formalize it would be 
to provide some sort of pre-approval process that is guaranteed 
to be checked by the core team (enhancement requests in bugzilla 
don't work, it's just too overstuffed with issues), so that 
contributors can be told _before_ they work on something whether 
it's likely to get serious consideration.  Maybe a wiki page 
that's monitored by the core team?


Swift also has the converse, a list of issues that are unlikely 
to be accepted:


https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

- There's a couple mentions of tooling, but I don't get the 
impression that source formatters and parsers are what people 
have in mind.  I think they're talking about bugs or holes in the 
core tools, ie compilers, linkers, and debuggers.  This is a 
problem for any OSS project that doesn't have a commercial model, 
to fund such quality of implementation issues that volunteers 
don't want to take up.

Re: Vision for the first semester of 2016

[Chris Wright via Digitalmars-d-announce]

On Sun, 24 Jan 2016 21:37:40 -0500, Andrei Alexandrescu wrote:

> Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei

I'm not fond of the militaristic terminology for participants. Novice, 
adept, master, maybe?

The section on safety is pretty short. I'd like to see in it:
* Guidelines for what should be made @trusted in Phobos (should we trust 
Win/Posix API functions? should we only trust wrappers that take D arrays 
rather than pointers? can we, for instance, create a @trusted wrapper 
around curl?)
* Efficiency / safety tradeoff guidelines (should Phobos provide a 
slightly faster implementations of things that aren't @safe? In those 
cases, should it provide both @safe and fast alternatives?)
* @safe / @trusted IO as a goal

As is, there are a smattering of things in Phobos that aren't @safe but 
seem like they could or should be, with no explanation and no safe 
alternatives. I think almost all IO is @system. This makes it hard and 
sometimes confusing to try to write @safe code.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

On 25/01/16 6:47 PM, Puming wrote:

On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:

On 25/01/16 4:21 PM, Puming wrote:

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


For PRs, I suggest the goal to be number of PRs MERGED instead of
created. That may provide the core team a subconsious incentive to look
at long pending PRs and hit a good cycle.

For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
seems a good candidate(native D, crossplatform). A good official
supported GUI library will attract many people.


That won't be happening anytime soon.
Until we have image and windowing in Phobos (I'm working on both)
there is no way a GUI toolkit is going in. And from what I know there
will be a LOT of work to update it.


Well I'm not saying that a GUI toolkit should go into Phobos.
I'd rather it stand alone, while taking some official support, say, link
in D frontpage(like visualD).


I want us to hold off on that as well.
I want people to really have a go with making GUI toolkits in D without 
the worry about how to do the cross platformy technical things.


We just don't know what could be done yet and I'm looking forward to 
finding out.

Re: Vision for the first semester of 2016

[Jack Stouffer via Digitalmars-d-announce]

On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:

Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei


My biggest issue with these documents is that they have good 
ideas but rarely have plans to achieve them. As a consequence, 
most of these documents say how half or more of the previous 
goals were not achieved.


I believe the best way to fix this is to simply have more focus. 
Have one large goal that can be broken down into smaller subsets, 
e.g. "2016 will be the year of a GC free Phobos". Something that 
has a very clear way of quantifying its success and a clear path 
to that goal.


Not that that the other things are not important, but if you 
constantly find yourself failing to meet your goals, the only 
rational option is to become more realistic in your plans.

Re: Vision for the first semester of 2016

[Puming via Digitalmars-d-announce]

On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole 
wrote:


I want us to hold off on that as well.


I agree that we need a more solid base.

I want people to really have a go with making GUI toolkits in D 
without the worry about how to do the cross platformy technical 
things.


Is dlangui a good start on this?



We just don't know what could be done yet and I'm looking 
forward to finding out.


I think improving dlangide will give us many opportunities for 
what a good D native GUI library needs.

Re: Localization (i18n) Options

[Luis via Digitalmars-d]

On Sunday, 24 January 2016 at 19:18:28 UTC, Gerald wrote:

On Monday, 18 January 2016 at 09:04:48 UTC, Luis wrote:
Please, write a HowTo some where. GtkD lack of documentation 
it's very anoying.


I've gotten this going with Terminix and posted some 
information what it took to get it going here:


http://gexperts.com/wp/gtkd-and-localization/


:thumbsup:

Re: [dlang.org] Let's talk about the logo

[anonymous via Digitalmars-d]

On 22.01.2016 00:46, anonymous wrote:

http://i.imgur.com/eJaKFtx.png

[...]

For dlang.org, I'd choose the version with the wide background arc. I
think it looks nice on the menu bar, and it puts a little more emphasis
there than just the core shape. But just the core shape looks fine, too.


I made a pull request for the wide one (the third one from the top):

https://github.com/D-Programming-Language/dlang.org/pull/1212

Last revision of phobos and druntime that actually compile with cdmd

[Benjamin Thaut via Digitalmars-d]

I'm currently merging a pretty large change over the C++->D 
boundary within Dmd. This change includes many changes to 
druntime and phobos. So I need the last revision of druntime and 
phobos that still compile with cdmd exactly before the switch was 
made. Unfortunately there is no git tag for this in druntime and 
phobos. I tried using a commit which was the same date as the 
cdmd -> ddmd switch but that didn't work.


Kind Regards
Benjamin Thaut

Re: Possible to get Class of Interface at runtime

[Josh Phillips via Digitalmars-d-learn]

On Saturday, 23 January 2016 at 21:06:32 UTC, Adam D. Ruppe wrote:

Are you sure you correctly casted first?


Nope sorry. Thanks for the help!!

Re: Downtime of gdc ftp, bugzilla, site, et. al.

[Iain Buclaw via Digitalmars-d]

On Sunday, 24 January 2016 at 12:09:06 UTC, Iain Buclaw wrote:

Hi,

I will be doing some long overdue maintenance to all services 
hosted on gdcproject.org.  This is starting with a backup of 
all data / configuration, followed by a complete rebuild.


First service that I'll try to bring up in a timely manner is 
the FTP site, though that largely depends on upload time 
(there's about 5GB worth to rsync over).


Apologies for any inconvenience.
Iain.



All services are back up.  GDC explorer is in a partial state 
(currently getting ARM, AArch64, PPC, and PPC64 disassemblers 
working).


There are still many tarballs missing on the ftp as upload is 
slow-slow-slow. :-(


Iain.

Tutorial on using eclipse with D

[Minas Mina via Digitalmars-d-announce]

Another IDE tutorial!

Reddit post:
https://www.reddit.com/r/programming/comments/42gcxi/using_eclipse_ide_with_d/

Re: very simple pure CPU raymarching demo

[karabuta via Digitalmars-d-announce]

On Sunday, 24 January 2016 at 14:18:23 UTC, ketmar wrote:
ok, just4fun, mulththreaded renderer[1]. set ThreadCount to 
number of your CPU cores to get some speedup.


note: this is not how `std.concurrency` should be used! please, 
don't do wroker queues as i did!


[1] http://ketmar.no-ip.org/dmd/zrm3_adam_trd_x4.d



This is the kind of maths I hoped I could try to understand. The 
spirit is not there :)

Re: very simple pure CPU raymarching demo

[ketmar via Digitalmars-d-announce]

This is the kind of maths I hoped I could try to understand. 
The spirit is not there :)

it's very easy, actually.

the basic idea is this: our "primitive" functions returns 
distance from a given point to the primitive. i.e.


auto point(1, 2, 3);
float dist = BoxPrimitive(point);

now `dist` is a distance from `point` to our box. it's by 
definition a shortest possible distance, of course.


now, to trace a ray, we are doing basically this:

try all primitives and find the minimal distance to ray origin.

then we know that we can safely move ray forward by that 
distance, 'cause it won't hit anything by the way. so move it, 
and repeat the process.


stop when we made some number of steps or minimal distance is 
less then some threshold.


whoa, we succesfully found our hitpoint! (and with some trick we 
also know wich primitive we hit)


basically, that's all. now just fire rays for all screen pixels, 
and color the pixels according to primitive color, adding some 
lighting to make image sexy.


the math is our ordinary vector algebra and light calculation, 
nothing arcane.


to calculate lights, we can use the same "find minimal distance" 
function to get light intencity for the given point. this is a 
win, 'cause we don't have to really trace a ray here.


of course, this is the simpliest case: light without shadow 
casting. to cast shadows, we have to trace a ray for real.


using "distance field" will allow us to do some more tricks too: 
easy soft shadows, ambient occlusion and others. they are, of 
course, possible with traditional raytracing too, but more 
expensive.


of course, the more objects our scene has, the slower it renders, 
as we don't try to do any space partitioning.


something like that. the code is really simple, just try to work 
out some simple primitive formula, and you'll get it.

Re: [dlang.org] Let's talk about the logo

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 24 January 2016 at 13:03:36 UTC, Ola Fosheim Grøstad 
wrote:

Meritocracy is not a horrible concept though.


Err, type. I meant to say that is a horrible concept. It is 
better than seniority, but makes no sense outside a hierarchical 
power structure IMO.

Re: Output range for file?

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

On Sun, Jan 24, 2016 at 12:38:22PM +, Tofu Ninja via Digitalmars-d-learn 
wrote:
> I tried looking for this in phobos but cant seem to find it which is
> really annoying. For my uses this works:

What kind of data do you need to write to file?  If it's textual data,
use File.lockingTextWriter, which is an output range.

If it's binary data, you'll probably have to roll your own; there's a
Phobos PR right now that implements File.lockingBinaryWriter, but it's
not quite ready for merging yet.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and 
let the world mirror it. -- Linus Torvalds

Ever want to compile D on your Android phone? Well, now you can!

[Joakim via Digitalmars-d-announce]

An alpha release of ldc, the llvm-based D compiler, for Android 
devices is now available.  It is best used with the excellent 
Termux app 
(https://play.google.com/store/apps/details?id=com.termux=en) 
and a bluetooth keyboard. ;) Updated test runners, that run most 
tests from the standard library on any Android device, are also 
available (results have been reported for everything from a 
TomTom BRIDGE GPS navigation device to a Huawei Watch):


https://github.com/joakim-noah/android/releases/tag/polish

You can install a test runner app or run a command-line binary.  
Please report your results in this thread in the ldc forum, which 
requires no registration, with the info and format requested 
there, particularly for Android 4.1 or earlier:


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

If you try out the native compiler, take a look at the README 
that comes with it for instructions.


If you have a D/OpenGL app you'd like to port to Android and 
submit to the Play Store, let me know if I can help with that 
process.

Re: First project: questions on how-to, and on language features

[Chris Wright via Digitalmars-d-learn]

On Sun, 24 Jan 2016 06:07:13 +, Alex Vincent wrote:

> Source code:
> https://alexvincent.us/d-language/samples/intervalmap-rev1.d.txt

There is no documentation, so I have no idea what you're trying to 
achieve here. So your questions about why this isn't in Phobos, whether 
there are any other libraries that do this, and whether there's a way to 
simplify your contracts are impossible for me to answer.

I notice you're using identifiers that start with double underscores. I'd 
recommend not making a habit of that. The compiler generates symbols for 
some things, and those symbols start with a double underscore.

For example:

  class Foo {
this(int i) {}
void __ctor(int i) {}
  }
  auto f = new Foo(1);

This produces an error like:

dubleuscore.d(13): Error: dubleuscore.Foo.__ctor called with argument 
types (int) matches both:
dubleuscore.d(4): dubleuscore.Foo.this(int i)
and:
dubleuscore.d(7): dubleuscore.Foo.__ctor(int i)

The compiler can add more such identifiers without warning, which could 
break your code in interesting ways.

> After reading Ali Çehreli's book, "Programming in D", I wrote this
> little sample up as a starting point for my explorations into D.  I've
> long admired the D language, but I've never actually tried to write
> practical code in D.
> 
> So I wrote this little sample up in dlangide, and as I was going,
> I realized I had quite a few questions.
> 
> (1) It's not clear how to specify certain parts of a module or library
> as non-exportable.  Is that possible?  Is it desirable? (It's not that
> important, yet, but still...)

As Marc mentioned, the 'private' keyword. You can use it directly:

  private int f;
  int g;  // implicitly public

in blocks:

  private {
int h;
int i;
  }
  int j;  // implicitly public

or label style:

  private:
  int k;
  int m;
  public int n;  // have to explicitly mark anything else public

That's all module-local. If you need to restrict things to your package, 
you can use the 'package' keyword, which functions identically.

All these syntax variants work everywhere. I find it handy, for instance, 
to write my code like:

  class Foo {
private {
  // fields go here
}
// everything else is generally public
  }

Aside from that, if you do not add a documentation comment to something, 
it will not be mentioned at all in the generated documentation. This 
makes it difficult for users to discover, in case you really need 
something to be public but don't want people to use it. But using 
'package' rather than 'public' will usually suffice in those cases.

> (3) How do I actually create a library in dub?  How does dub determine
> what files to build?

I believe Dub includes all files by default.

> (4) How should the scope(exit) and scope(failure) guard statements
> intermix with preconditions and postconditions?

Marc answered this, but while we're on the topic of preconditions, I 
notice your usage of enforce:

  enforce(index > upperEdge, new StringException("index must be greater 
than upperEdge"));

The idiom in use in Phobos is:

  enforce!StringException(index > upperEdge, "index must be greater than 
upperEdge");

Re: DIP 88: Simple form of named parameters

[Chris Wright via Digitalmars-d]

On Sun, 24 Jan 2016 11:20:20 +, Gary Willoughby wrote:

> On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg wrote:
>> This is mostly to prevent ugly hacks like Flag [1].
>>
>> http://wiki.dlang.org/DIP88
> 
> "A new syntax is added to be used when declaring a function that should
> be callable with named parameters:"
> 
> Please, no more new syntax!
> 
> This can be done using templates and Flag is not an ugly hack!

Okay, but only part of this has to do with booleans. Taking your proposal 
to its logical conclusion, you're saying I should write:

alias Typedef!(string, "key") Key;
alias Typedef!(string, "startDocumentID") StartDocumentID;
alias Typedef!(ulong, "limit") Limit;
alias Typedef!(ulong, "resultsPerPage") ResultsPerPage;

CouchPaginatedRange query(
  Key key = Key(""),
  StartDocumentID startID = StartDocumentID(""),
  Limit limit = Limit(ulong.max),
  ResultsPerPage resultsPerPage = ResultsPerPage(50),
  Flag!"includeDocuments" includeDocuments = No.includeDocuments) {}

query(Key("foo"), Yes.includeDocuments);

This is an interesting proposal, but I'll only ever consider it if Walter 
says we're never getting sparse named arguments.

Re: Output range for file?

[Tofu Ninja via Digitalmars-d-learn]

On Sunday, 24 January 2016 at 15:08:33 UTC, H. S. Teoh wrote:
On Sun, Jan 24, 2016 at 12:38:22PM +, Tofu Ninja via 
Digitalmars-d-learn wrote:
I tried looking for this in phobos but cant seem to find it 
which is really annoying. For my uses this works:


What kind of data do you need to write to file?  If it's 
textual data, use File.lockingTextWriter, which is an output 
range.


If it's binary data, you'll probably have to roll your own; 
there's a Phobos PR right now that implements 
File.lockingBinaryWriter, but it's not quite ready for merging 
yet.



T


I am writing out binary data, so I guess I will just keep using 
what I am using.

Re: What have I missed?

[Era Scarecrow via Digitalmars-d]

On Thursday, 7 August 2014 at 10:08:30 UTC, Marc Schütz wrote:
I haven't looked at your rewrite, but from what I've seen the 
current implementation is indeed very awkward and full of bugs. 
There were also some discussions about the behavior on resizing 
with respect to stomping, IIRC. This seems to imply that not 
even the semantics are completely clear. I guess a complete 
rewrite would be appropriate in such a situation.


 Fun... I'll go through for the most recent version of DMD and 
see about porting my changes over in smaller bite-sized chunks 
and see if it won't be accepted. This might be easier than 
figuring out all the changes in the D language and figuring them 
out as I come across them (not that I used many of the features 
beyond templates and operator overloading).


 That is assuming this is still the case (it's been a year 
afterall). Hmmm. Off hand I'm remembering there was the issue of 
'sometimes a var sometimes a value sometimes a ref' that was 
popping up when it switched over to allocated memory when the 
array got beyond a certain size. There's something I still need 
to figure out.

Re: DIP 88: Simple form of named parameters

[Chris Wright via Digitalmars-d]

On Sun, 24 Jan 2016 13:04:20 +0100, Jacob Carlborg wrote:
> On 2016-01-23 19:27, Chris Wright wrote:
>> I'd also add that this proposal doesn't affect UFCS.
> 
> How would it affect UFCS?

It shouldn't. However, it is another way to pass function arguments, so 
for thoroughness it would be better to mention it.

>> I'll note that parameter names are already part of documentation, and
>> they're already the only parameter documentation you're guaranteed to
>> have.
> 
> Currently it's possible to change a parameter name without the call site
> needing any change. Documentation has nothing to do with that.

I mentioned this because it strongly encourages people to use appropriate 
and descriptive names when writing functions. Appropriate and descriptive 
names are less likely to need to change. This doesn't eliminate your 
point that, today, people can change argument names and be guaranteed not 
to break client code.

>> Given this trend, people will be confused if they can't reorder named
>> parameters. The main benefit of not letting people reorder things is
>> reducing the amount of work *you* need to do when creating this DIP
>> (and the amount others need to do when implementing it).
> 
> No. The only reason why that is not allowed is to have a greater chance
> of the DIP being accepted. The language would be even more complicated
> if it was possible to reorder the arguments. It's a benefit for the
> users if the language is simpler.

There's more chance of it being rejected as not sufficiently beneficial 
and less chance of it being rejected as too much complexity. But let's 
look at that complexity angle. What sort of complexity do we want to 
eliminate?

There was recently a post that made the point that an hour of time from a 
compiler developer making something easier and saving each user an hour 
of time is a huge productivity gain in all. So we want to reduce 
complexity for language users, and making a more complex compiler is only 
problematic insofar as it makes the compiler slower or buggier.

All else being equal, adding constraints generally adds complexity and 
removing them generally reduces complexity. Any constraint we add has to 
pay for its complexity somehow. Having to remember parameter order while 
specifying unambiguously which parameter I'm trying to use is an added 
constraint and therefore added complexity. It gives nothing in return.

Since absolutely no language has previously required named arguments to 
retain the same order they're declared in, apparently everyone else 
disagrees that the feature is too complex. Even Python, which is 
specifically aimed at beginners, allows reordering.

The most similar thing to named parameters that's already in D is struct 
initializers. These do not require that you order the struct member 
initializers in the same order as the related fields are declared. This 
means that users have to remember two sets of similar syntax that 
function differently in an important way. That's added complexity within 
D.

It's a benefit to users if things work in a familiar way. I haven't been 
able to find a language that works in the way you propose, so for people 
familiar with other languages, this DIP results in confusing behavior. 
That's added complexity across languages. And since D doesn't have the 
same market penetration that Java or Javascript have, it's extremely 
difficult for a person to be familiar only with D.

>> Document how it's supposed to handle optional parameters
> 
> It's already documented.

I missed that. My apologies.

Your proposal says this works:

  void foo(int a: = 3, int b: = 4);
  foo();
  foo(a: 5, b: 6);

But we can conclude that the following is not allowed:

  foo(b: 6);

This is because it's not legal to change the order of arguments by 
specifying names, and you must supply optional parameters of the same 
type in order, without omitting any, if you don't have names. Your 
proposal did not involve any special casing here.

Is this what you intended? If so, please document it so other reviewers 
don't have to wonder.

[Issue 15601] New: version not allowed within enum declaration

[via Digitalmars-d-bugs]

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

  Issue ID: 15601
   Summary: version not allowed within enum declaration
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@atari8.info

The following declaration is not accepted. Compiler complains "Error: basic
type expected, not version".
It can be worked around by versioning the entire enum declaration (code
duplication) or string mixin (ugly).

enum snd_pcm_format_t
{
UNKNOWN = -1,
S8 = 0,
U8,
S16_LE,
S16_BE,
U16_LE,
U16_BE,
S24_LE,
S24_BE,
U24_LE,
U24_BE,
S32_LE,
S32_BE,
U32_LE,
U32_BE,
FLOAT_LE,
FLOAT_BE,
FLOAT64_LE,
FLOAT64_BE,
IEC958_SUBFRAME_LE,
IEC958_SUBFRAME_BE,
MU_LAW,
A_LAW,
IMA_ADPCM,
MPEG,
GSM,
SPECIAL = 31,
S24_3LE = 32,
S24_3BE,
U24_3LE,
U24_3BE,
S20_3LE,
S20_3BE,
U20_3LE,
U20_3BE,
S18_3LE,
S18_3BE,
U18_3LE,
U18_3BE,
G723_24,
G723_24_1B,
G723_40,
G723_40_1B,
DSD_U8,
DSD_U16_LE,
LAST = DSD_U16_LE,

version(LittleEndian)
{
S16 = S16_LE,
U16 = U16_LE,
S24 = S24_LE,
U24 = U24_LE,
S32 = S32_LE,
U32 = U32_LE,
FLOAT = FLOAT_LE,
FLOAT64 = FLOAT64_LE,
IEC958_SUBFRAME = IEC958_SUBFRAME_LE
}
else version(BigEndian)
{
S16 = S16_BE,
U16 = U16_BE,
S24 = S24_BE,
U24 = U24_BE,
S32 = S32_BE,
U32 = U32_BE,
FLOAT = FLOAT_BE,
FLOAT64 = FLOAT64_BE,
IEC958_SUBFRAME = IEC958_SUBFRAME_BE
}
else
{
static assert(0, "Unknown endian");
}
}

--

Re: DIP 88: Simple form of named parameters

[Chris Wright via Digitalmars-d]

On Sun, 24 Jan 2016 10:14:53 +, default0 wrote:
> So given this method:
> void M(int a, int b = 1, int c = 2, int d = 3, int e = 4, int f =
> 5, int g = 6, int h = 7, int i = 8)
> {
> }
> 
> You prefer calling it this way:
> M(5, 1, 2, 3, 4, 5, 6, 7, 23);
> As opposed to:
> M(5, i: 23);

Actually, the proposal doesn't allow the latter. It explicitly doesn't 
allow you to change the order of parameters and says nothing about 
allowing this as a special case, so you would have to write it as:

M(5, b: 1, c: 2, d: 3, e: 4, f: 5, g: 6, h: 7, i: 23);

Which is slightly more readable but still a nightmare for maintainability.

[Issue 15582] Slice returned by opSlice() not accepted as lvalue

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #6 from Marc Schütz  ---
@H. S. Teoh:

You're right that opSlice() should actually be opIndex(), but this has nothing
to do with the problem (I guess we both agree on that).

I may indeed be misunderstanding things. Let me comment on some of your points,
maybe my stance becomes clearer.

> Secondly, in opSlice()'s implementation, the notation `data[]` means "take a
> slice of the static array `data`", IOW, "make a dynamic array that points to
> the elements of the static data `data`".

Right. To clarify, since this may be a cause of confusion, what I mean by
"slice" is exactly a "dynamic array".

> So what you end up with, is that the LHS of the assignment is a dynamic array,
> and you're trying to assign the scalar 10 to it. This is, of course, invalid.

This is where I used to disagree. In my understanding, the language should
behave as if dynamic arrays `T[]` had an operator `T opAssign(T value)` that
does element-wise assignment.

Now, looking at [1], the documentation indeed describes the expected behaviour
in terms of a "slice operator", thus supporting your point of view.

> If the line marked "array copying notation" is really the same thing as
> slicing, then the line "x = y" ought to overwrite the first two elements of a
> with the last two elements of b.

I'm aware of this. But in `x = y`, `x` is an lvalue, see my comment #4.

But in light of what the specification says, the current behaviour is indeed
consistent. It seems that my mental model was indeed different.

I still think that the current behaviour is suboptimal, but it's certainly not
a bug then. I'm turning this into an enhancement request; people can close it
if it isn't useful.

[1] http://dlang.org/spec/arrays.html#array-setting

--

[Issue 15599] Broken link here: https://dlang.org/features2.html

[via Digitalmars-d-bugs]

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

Marc Schütz  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schue...@gmx.net
 Resolution|--- |FIXED

--- Comment #1 from Marc Schütz  ---
The entire page has been deemed as unnecessary and was therefore removed:

https://github.com/D-Programming-Language/dlang.org/pull/1209
https://github.com/D-Programming-Language/dlang.org/pull/1211

--

Re: DIP 88: Simple form of named parameters

[Chris Wright via Digitalmars-d]

On Sun, 24 Jan 2016 08:16:35 -0500, Michel Fortin wrote:

> Have you considered supporting separate variable names? Like this:
> 
>   void login(string username: name, string password:) {
>   writeln(name ~ ": " ~ password);
>   }

You mean:

  void login(string username:, string password:) {
alias name = username;
writeln(name, ": ", password);
  }

Re: Localization (i18n) Options

[Gerald via Digitalmars-d]

On Monday, 18 January 2016 at 09:04:48 UTC, Luis wrote:
Please, write a HowTo some where. GtkD lack of documentation 
it's very anoying.


I've gotten this going with Terminix and posted some information 
what it took to get it going here:


http://gexperts.com/wp/gtkd-and-localization/

[Issue 15602] New: Write GC profiling summary to stderr rather than stdout (--DRT-gcopt=profile:1)

[via Digitalmars-d-bugs]

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

  Issue ID: 15602
   Summary: Write GC profiling summary to stderr rather than
stdout (--DRT-gcopt=profile:1)
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: jrdemail2000-dl...@yahoo.com

When running a program with --DRT-gcopt=profile:1, GC statistics are written to
stdout when the program terminates. Writing the statistics to stderr would be
an improvement for programs that write to stdout as part of normal operating
behavior. For example, unix pipe style programs.

--