Re: Fixed size array initialization

[rumbu via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 01:26:59 UTC, psychoticRabbit 
wrote:
On Sunday, 11 February 2018 at 01:13:00 UTC, psychoticRabbit 
wrote:


Well, in C.. I can do:

int arr[2] = { [0]=10, [1]=20 };

I cannot work out how to do that in D yet (anyone know??)



Oh. just worked it out after reading this thread ;-)

int[2] arr = [ 0:10, 1:20 ];


This is indeed the most simple and elegant solution. Thanks.

Re: Which language futures make D overcompicated?

[Pjotr Prins via Digitalmars-d]

Dub is getting some flak here. This is unsurprising because it is 
really hard to write a good package manager and build system. I 
use a lot of languages and not one has a satisfactory package 
manager. Mostly they try to do too much and get in the way or 
they do too little and people complain (I prefer the second 
option). And when there are 100+ dependencies, like with Go and 
Node, it just becomes impossible to say anything about the state 
of the system (security, anyone?).


Package management is mostly dependency management. This I handle 
with GNU Guix (and Nix) package managers. They are great at that. 
This also leaves people to choose any old build system. Inside 
GNU Guix the build system is consistent, which is really nice. 
I'll write a blog some time this year.


What you really want is to be able to discover packages (i.e., a 
website such as Dub provides), pull them into your tree (which is 
just a path and can be handled by git submodules, though I don't 
like those much either), and when you distribute: add them to 
Guix or Nix and provide those packages with build system and as 
binary deployments to others. These package managers give control 
over the full dependency graph, including shared libraries all 
the way down to glibc.


I am not posting this to plug these systems per se. Just saying 
that writing a generic package manager is hard and is better left 
to systems that solve handling the full dependency graph 
correctly. Personally, I am happy very happy with what Guix gives 
me. Can't think of a better way. I have no reason to use dub.

Re: dub segfault

[Joe via Digitalmars-d]

On Sunday, 11 February 2018 at 00:59:10 UTC, Seb wrote:
Ideally you could verify whether this also happens with the 
official release.


Installing the official (ldc) release doesn't cause the problem, 
so presumably this is a problem with the Debian buster release.  
However, I notice the official dub reports as version 1.6.0 built 
on 6 Jan, whereas the official ldc is 1.7.0 and the Debian dub 
is, as mentioned before, 1.7.0-2, and the Debian ldc2 says it's 
version 1.5.0, based on DMD 2.075.1, i.e., the version numbers 
are confusing to say the least.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/10/2018 7:27 PM, Jonathan M Davis wrote:

And it's already kind of silly
that we have as many comment types as we do.


Even more comment types implies we don't know what we're doing :-(

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 10, 2018 18:53:03 Walter Bright via Digitalmars-d 
wrote:
> On 2/10/2018 6:28 PM, Timothee Cour wrote:
> > all these workarounds are rather ugly; the proposed syntax works all
> > the time (user can just pick a EOC token not in comment) and is analog
> > to existing D heredoc strings, so nothing surprising there.
> > Would PR's be accepted?
>
> You'll need to make a stronger case for it.
>
> D already has 3 kinds of comments. You can pick a different kind if there
> are conflicting characters with one of them. Or use the mentioned escape
> methods.

Personally, the _only_ time that I have ever had a problem with D's nested
comments is when I was working on a lexer. I was forced to use version none
when commenting out code that involved nested comments - especially the unit
tests for malformed comments.

In general, nested comments just work perfectly. So, while dealing with the
rare cases where they're a problem may be annoying, it's just not the sort
of thing that most code has to worry about. And it's already kind of silly
that we have as many comment types as we do.

- Jonathan M Davis

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/10/2018 6:28 PM, Timothee Cour wrote:

all these workarounds are rather ugly; the proposed syntax works all
the time (user can just pick a EOC token not in comment) and is analog
to existing D heredoc strings, so nothing surprising there.
Would PR's be accepted?


You'll need to make a stronger case for it.

D already has 3 kinds of comments. You can pick a different kind if there are 
conflicting characters with one of them. Or use the mentioned escape methods.

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Timothee Cour via Digitalmars-d]

all these workarounds are rather ugly; the proposed syntax works all
the time (user can just pick a EOC token not in comment) and is analog
to existing D heredoc strings, so nothing surprising there.
Would PR's be accepted?


On Sat, Feb 10, 2018 at 5:01 PM, Jonathan M Davis via Digitalmars-d
 wrote:
> On Saturday, February 10, 2018 15:03:08 Walter Bright via Digitalmars-d
> wrote:
>> On 2/8/2018 7:06 PM, Timothee Cour wrote:
>> > /"EOC
>> > This is a multi-line
>> > heredoc comment allowing
>> > /+ documented unittests containing nesting comments +/
>> > and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
>> > EOS"/
>>
>> There isn't any commenting scheme that won't trip you up with certain
>> characters in the comments. I don't see a compelling case for adding
>> another kind of comment.
>>
>> Vladimir's suggestion to use %2B instead of + seems to resolve this
>> adequately.
>
> You could also always just declare a DDOC macro.
>
> Just put
>
> Macros:
> PLUS=+
>
> in the ddoc comment and then use $(PLUS) instead of +. It's more verbose
> that way given that PLUS isn't one of the standard ddoc macros, but it's
> more idiomatic to look at.
>
> - Jonathan M Davis
>

[Issue 16578] bogus deprecation - switch skips declaration of variable

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
The problem seems to be due to the associative array.
Reduced a bit further:

---
import std.stdio;

void main()
{
string[string] opts;
switch (2)
{
case 0:
opts["a"] = "";
{
case 1:
break;
}
default:
}
}
---

--

How can I get the new stdout which changes periodically from a process?

[Marc via Digitalmars-d-learn]

I do call a program from my application which changes its stdout 
perdiodically (with ncurses library, I guess), where I'd to get 
somehow "notified" when some change happen (I need to new data 
from that changes and change my application accordingly). 
Currently, I do use spawnProcess() which runs the app in paralel 
but I have no idea how to capture periodically changes in its 
stdout.
It doesn't need to be exact; like a notification for every single 
change. If it checks for changes and report if there's any, every 
say, x seconds is enough.

Re: Linking multiple libraries

[b2.temp--- via Digitalmars-d-learn]

On Sunday, 26 November 2017 at 11:15:58 UTC, Jacob Carlborg wrote:

On 2017-11-25 23:31, Mike Parker wrote:

For "ld" on macOS the order does not matter. For "ld" on Linux 
the order does matter, but, if necessary, the following flags 
can be used to link libraries in any order: "--start-group" and 
"--end-group". Those flag will cause the linker to search the 
libraries repeatedly to resolve undefined symbols.


These flags should be  passed to ld by DMD i think

[Issue 8166] retro() of splitter() too

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

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

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

https://github.com/dlang/phobos/commit/c7b6aabfea45b2151f0f21548232242e896101d6
Issue 8166 - retro() of splitter() too

https://github.com/dlang/phobos/commit/508337e0bbd3aba17e9235a0229b032da72b318d
Merge pull request #6150 from wilzbach/splitter-back

Issue 8166 - remove dead _backLength code in std.algorithm.splitter
merged-on-behalf-of: Sebastian Wilzbach 

--

Re: typedef behavior

[Alex via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 02:55:26 UTC, Alex wrote:

bug filed

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

[Issue 18416] New: Different Typedef share addresses of static arrays

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

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

  Issue ID: 18416
   Summary: Different Typedef share addresses of static arrays
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

Defining two Typedefs with different cookies, based on a struct with a static
array, leads to different types, which shares the static array.

/// --- code --- ///
import std.typecons; 
import std.traits; 

static assert(!is(MyEA == MyEB));
static assert(!is(MyEA == E));
static assert(!is(MyEB == E));

void main()
{
MyEA ea; 
MyEB eb; 
eb.tarr.length = 4;

assert(ea.tarr.ptr != eb.tarr.ptr); // line 14
assert(ea.tarr.length != eb.tarr.length); // line 15
}

struct T { size_t i; }

struct E
{
size_t i; 
static T[] tarr;
}

alias MyEA = Typedef!(E, E.init, "A");
alias MyEB = Typedef!(E, E.init, "B");

/// --- code ends --- ///

Line 14 and 15 yields both an error, which is unexpected. See also
https://forum.dlang.org/thread/ceilfwjlagdbyguda...@forum.dlang.org

--

Re: Fixed size array initialization

[psychoticRabbit via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 01:13:00 UTC, psychoticRabbit 
wrote:


Well, in C.. I can do:

int arr[2] = { [0]=10, [1]=20 };

I cannot work out how to do that in D yet (anyone know??)



Oh. just worked it out after reading this thread ;-)

int[2] arr = [ 0:10, 1:20 ];

[Issue 18415] Typedef ignores @disabled default constructor

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

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

Alex  changed:

   What|Removed |Added

 CC||sascha.or...@gmail.com

--

Re: typedef behavior with @disable this()

[Alex via Digitalmars-d-learn]

On Sunday, 11 February 2018 at 00:54:07 UTC, Simen Kjærås wrote:


Typedef explicitly initializes the wrapped value to T.init, 
thus circumventing the disabled default constructor. Filed a 
bug:


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

--
  Simen


Thanks!

Re: Fixed size array initialization

[psychoticRabbit via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote:


I have a large static initialized array, let's say int[155], 
and I forgot to declare the last element:


int[155] myarray = [
  a,
  b,
  c,
  ...
  //forgot to declare the 155th element
];



Well, in C.. I can do:

int arr[2] = { [0]=10, [1]=20 };

I cannot work out how to do that in D yet (anyone know??)

In the meantime, I'd suggest doing it this way, as you're more 
likely to see that whether you forgot an element:


int[2] arr;
{
arr[0] = 10;
arr[1] = 20;
}

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 10, 2018 15:03:08 Walter Bright via Digitalmars-d 
wrote:
> On 2/8/2018 7:06 PM, Timothee Cour wrote:
> > /"EOC
> > This is a multi-line
> > heredoc comment allowing
> > /+ documented unittests containing nesting comments +/
> > and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
> > EOS"/
>
> There isn't any commenting scheme that won't trip you up with certain
> characters in the comments. I don't see a compelling case for adding
> another kind of comment.
>
> Vladimir's suggestion to use %2B instead of + seems to resolve this
> adequately.

You could also always just declare a DDOC macro.

Just put

Macros:
PLUS=+

in the ddoc comment and then use $(PLUS) instead of +. It's more verbose
that way given that PLUS isn't one of the standard ddoc macros, but it's
more idiomatic to look at.

- Jonathan M Davis

[Issue 18322] void fun(string file=__FILE_FULL_PATH__)() returns relative path (pointing to nowhere)

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

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

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

https://github.com/dlang/dmd/commit/1927521a0450c9904a9ed8bada1a2b5f9a506718
Fix issue 18322

https://github.com/dlang/dmd/commit/6a2db254e9f0185676713db481ee3780d65bea68
Merge pull request #7798 from marler8997/bug18322

Fix issue 18322: __FILE_FULL_PATH__ doesn't work as a template parameter
merged-on-behalf-of: Mike Franklin 

--

Re: dub segfault

[Seb via Digitalmars-d]

On Sunday, 11 February 2018 at 00:31:28 UTC, Joe wrote:
I'm getting a segmentation fault when I run 'dub build' and I 
specify a dependency. Specifically, the dependency is 
'derelict-pq' but it could be anything (I tried 'dpq2' and even 
'mysql-native', just for kicks). The segfault occurs when it's 
supposedly searching for the dependency.  Here's the partial 
output of 'dub --vverbose build'


Collecting dependencies for select
  Version selection for dependency derelict-pq (derelict-pq) of 
select is missing.
  Missing dependency derelict-pq >=3.0.0-beta.3 <3.1.0-0 of 
select

Checking for missing dependencies.
Search for versions of derelict-pq (1 package suppliers)
Segmentation fault

The dub.json is trivial and works to properly build a program 
with 'libpq' directly.  And two months ago I had built the 
derelict-pq sample program and AFAIR everything went fine.


When this first happened last night, code.dlang.org was 
temporarily not accessible but that's been resolved now.  
Before I report this as an issue, I thought I'd get some 
feedback.  I'm running dub 1.7.0-2, built on Jan  3 2018, on 
Debian buster.


DUB should never, ever segfault.
Please report an issue to the dub issue tracker 
(https://github.com/dlang/dub/issues) with a minimal example to 
reproduce. Thanks!



built on Jan  3 2018, on Debian buster.


Ideally you could verify whether this also happens with the 
official release.

The quick way to try this:

---
. $(curl https://dlang.org/install.sh | bash -s)
dub
---

See also: https://dlang.org/install.html

Re: typedef behavior with @disable this()

[Simen Kjærås via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 13:18:28 UTC, Alex wrote:

Do I overlook something?

/// --- code --- ///

import std.typecons;

void main(){}

static assert(!__traits( compiles, E()));
static assert(!__traits( compiles, MyE())); // line 6

struct E
{
size_t dummy;
@disable this();
this(size_t val) { dummy = val; }
}

alias MyE = Typedef!E;

/// --- code ends --- ///

While line 5 does not compile as expected, due to disabled 
default constructor, the Typedef'd type does. Why?


Typedef explicitly initializes the wrapped value to T.init, thus 
circumventing the disabled default constructor. Filed a bug:


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

--
  Simen

[Issue 18415] New: Typedef ignores @disabled default constructor

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

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

  Issue ID: 18415
   Summary: Typedef ignores @disabled default constructor
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: simen.kja...@gmail.com

When a type that has a disabled default constructor is used in
std.typecons.Typedef, it's possible to create an uninitialized instance of the
type, since Typedef doesn't disable its constructor:


unittest {
import std.typecons : Typedef;

struct S {
@disable this();
}

//S s1; // Fails horribly.
Typedef!S s1; // Compiles without issue.
}

--

[Issue 17982] Support for const(Class) in algorithm.searching.extremum

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
PR: https://github.com/dlang/phobos/pull/6157

> In the forum thread, @vit suggested using something like this instead:

Yeah that's a good idea.

--

Re: Quora: Why hasn't D started to replace C++?

[psychoticRabbit via Digitalmars-d]

On Sunday, 11 February 2018 at 00:15:32 UTC, Ola Fosheim Grostad 
wrote:
On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit 
wrote:
On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


Why indeed!

Feature D C C++ C# Java (and this was bacvk in
=


(correction to above line)
Feature D C C++ C# Java (and this was back in 2003)

..2003 ..gee.. that was what..15 years ago.


Well, it isn't correct in 2018...


Hence the reason why D hasn't started to replace C++.

i.e C++ continues to evolve..

(except that D got many things right, in the first instance - and 
so D can focus on more important matters ;-)

Re: Which language futures make D overcompicated?

[Arun Chandrasekaran via Digitalmars-d]

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:
I like D, but sometimes it's look like for me too complicated. 
Go have a lot of fans even it not simple, but primitive. But 
some D futures make it very hard to learning.


Small list by me:
1. mixins
2. inout
3. too many attributes like: @safe @system @nogc etc

Which language futures by your opinion make D harder?


Sorry for being pessimistic, but this has already been discussed 
many times here. This is just a waste of time and it doesn't 
produce any results.


Having coded in C++ all my life, I can definitely say C++ is way 
too complex. So D can't win it in that aspect. :-)


The main thing confused me a LOT, as ketmar rightly said, was 
struct (it was not TLS, it was not static, it was not GC). Other 
than that, there are a few that I can point in D that I consider 
are complex.


* auto decoding - given that ranges are the idiomatic way, it's 
simply unacceptable.

* shared
* immutable vs const
* lack of consistency and orthogonality. Past discussions: 
https://forum.dlang.org/post/iysrtqzytdnrxsqtf...@forum.dlang.org


From the perspective of language complexity, I'm already living 
with C++, so I can live with D as well. But the difficult thing 
to live with is


* Dearth of libraries (features, performance and quality)
* Dearth of libraries
* Dearth of libraries

dub segfault

[Joe via Digitalmars-d]

I'm getting a segmentation fault when I run 'dub build' and I 
specify a dependency. Specifically, the dependency is 
'derelict-pq' but it could be anything (I tried 'dpq2' and even 
'mysql-native', just for kicks). The segfault occurs when it's 
supposedly searching for the dependency.  Here's the partial 
output of 'dub --vverbose build'


Collecting dependencies for select
  Version selection for dependency derelict-pq (derelict-pq) of 
select is missing.

  Missing dependency derelict-pq >=3.0.0-beta.3 <3.1.0-0 of select
Checking for missing dependencies.
Search for versions of derelict-pq (1 package suppliers)
Segmentation fault

The dub.json is trivial and works to properly build a program 
with 'libpq' directly.  And two months ago I had built the 
derelict-pq sample program and AFAIR everything went fine.


When this first happened last night, code.dlang.org was 
temporarily not accessible but that's been resolved now.  Before 
I report this as an issue, I thought I'd get some feedback.  I'm 
running dub 1.7.0-2, built on Jan  3 2018, on Debian buster.

Re: Quora: Why hasn't D started to replace C++?

[Ola Fosheim Grostad via Digitalmars-d]

On Sunday, 11 February 2018 at 00:06:07 UTC, psychoticRabbit 
wrote:
On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


Why indeed!

Feature D C C++ C# Java (and this was bacvk in
=


(correction to above line)
Feature D C C++ C# Java (and this was back in 2003)

..2003 ..gee.. that was what..15 years ago.


Well, it isn't correct in 2018...

[Issue 4936] Better error when type inference fails due to incorrect template parameter type

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

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

Seb  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #4 from Seb  ---
This works:

---
import std.stdio, std.algorithm, std.range;
void main() {
   auto foo = ["a the way home", "can I say"];
   auto bar = ["be it here or there", "you may"];

   completeSort(foo.assumeSorted, bar.assumeSorted);
}
---

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

> Clearly, no one is using completeSort at all

Yeah if it's open for eight years, that's a very good sign no one uses it...
I'm closing this as it's too old for an regression and assumeSorted works.

--

[Issue 8341] topN(zip()) too?

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
PR https://github.com/dlang/phobos/pull/6156

--

Re: Quora: Why hasn't D started to replace C++?

[psychoticRabbit via Digitalmars-d]

On Sunday, 11 February 2018 at 00:03:16 UTC, psychoticRabbit 
wrote:
On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei 
Alexandrescu wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


Why indeed!

Feature D C C++ C# Java (and this was bacvk in
=


(correction to above line)
Feature D C C++ C# Java (and this was back in 2003)

..2003 ..gee.. that was what..15 years ago.

Re: Quora: Why hasn't D started to replace C++?

[psychoticRabbit via Digitalmars-d]

On Tuesday, 30 January 2018 at 20:45:44 UTC, Andrei Alexandrescu 
wrote:

https://www.quora.com/Why-hasnt-D-started-to-replace-C++

Andrei


Why indeed!

Feature D C C++ C# Java (and this was bacvk in
=
Garbage Collection Yes No No Yes Yes

Functions
=
Function delegates  Yes No No Yes No
Function overloadingYes No Yes Yes Yes
Out function parameters Yes Yes Yes Yes No
Nested functionsYes No No No No
Function literals   Yes No No No No
Dynamic closuresYes No No No No
Covariant return types  Yes No Yes No No

Arrays
==
Lightweight arrays  Yes Yes Yes No No
Resizeable arrays   Yes No No No No
Arrays of bits  Yes No No No No
Built-in stringsYes No No Yes Yes
Array slicing   Yes No No No No
Array bounds checking   Yes No No Yes Yes
Associative arrays  Yes No No No No
Strong typedefs Yes No No No No
Aliases Yes Yes Yes No No

OOP
===
Object Oriented Yes No Yes Yes Yes
Multiple InheritanceNo No Yes No No
Interfaces  Yes No Yes Yes Yes
Operator overloadingYes No Yes Yes No
Modules Yes No Yes Yes Yes
Dynamic class loading   No No No No Yes
Inner classes   No No No No Yes
Covariant return types  Yes No Yes No No

Performance
===
Inline assemblerYes Yes Yes No No
Direct access to hardware   Yes Yes Yes No No
Lightweight objects Yes Yes Yes Yes No
Explicit memory allocation control  Yes Yes Yes No No
Independent of VM   Yes Yes Yes No No
Direct native code gen  Yes Yes Yes No No
Templates   Yes No Yes No No

Reliability
===
Design by Contract  Yes No No No No
Unit testingYes No No No No
Static construction order   Yes No No Yes Yes
Guaranteed initialization   Yes No No Yes Yes
RAIIYes No Yes Yes No
Exception handling  Yes No Yes Yes Yes
try-catch-finally blocksYes No No Yes Yes
Thread synchronization primitives   Yes No No Yes Yes

Compatibility
=
Algol-style syntax  Yes Yes Yes Yes Yes
Enumerated typesYes Yes Yes Yes No
Support all C types Yes Yes No No No
Long double floating point  Yes Yes Yes No No
Complex and Imaginary   Yes Yes No No No
Direct access to C  Yes Yes Yes No No
Use existing debuggers  Yes Yes Yes No No
Struct member alignment control Yes Yes Yes No No
Generates standard object files Yes Yes Yes No No
Macro preprocessor  No Yes Yes No No

Other
=
Conditional compilation Yes Yes Yes Yes No

[Issue 9841] std.algorithm.iFilter

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
So summarizing the status quo in D is:

---
auto names2 = ["Sam", "Pamela", "Dave", "Pascal", "Erik"];
auto nameRange2 = names2.enumerate.filter!(a => a.value.length <=
a.index).map!(a => a.value);
nameRange2.writeln;
---

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

It's not too bad and I doubt that filterIndex would be accepted.

--

[Issue 8207] OS X: Should extern(D) symbols include another underscore?

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

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

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

   What|Removed |Added

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

--

[Issue 8172] OSX: symbols mangled on gdb,ggdb,cgdb,lldb but not on ubuntu; no line numbers on stacktraces

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

https://issues.dlang.org/show_bug.cgi?id=8172
Issue 8172 depends on issue 8207, which changed state.

Issue 8207 Summary: OS X: Should extern(D) symbols include another underscore?
https://issues.dlang.org/show_bug.cgi?id=8207

   What|Removed |Added

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

--

[Issue 8207] OS X: Should extern(D) symbols include another underscore?

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

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

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

https://github.com/dlang/dmd/commit/db2976599db44f2163986ba9cb541afd7cfa8471
fix Issue 8207 - extern(D) symbols should include another underscore

1. Removed ABI name fiddling from the front-end.
2. Removed `Target.prefixName` and C++ tests for matching `__Z`.
3. Prepend prefixes for C++ and D symbols in the backend only
   for the targets that require it (Win32, OSX).
4. Removed `RTLSYM__DINVARIANT` runtime library symbol, name is now
   the same on all targets.
5. Correctly set C++ mangling on `LINK.cpp` symbols, before they
   were all being set as D mangled symbols.
6. Use System mangling as synonym for do not modify symbol.
7. Added workaround for `extern(D) ___tls_get_addr`.

https://github.com/dlang/dmd/commit/9691eba9441f7f165359716f80f46486ea09fb46
Merge pull request #7620 from ibuclaw/ingcc2

fix Issue 8207 - extern(D) symbols should include another underscore
merged-on-behalf-of: unknown

--

[Issue 9871] std.typecons.asArray

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
> A simpler implementation:

Well, it's just:

---
tup.expand.only;
---


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

I'm not so sure whether this will be added to Tuple, but as Tuples will
hopefully soon be part of the language, they should be first-class range
citizens too.

--

Re: Getting a reference to an immutable string

[David Zhang via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 22:59:18 UTC, ag0aep6g wrote:
But there is a recent regression on Windows that might be 
related. Do you also have a static constructor (`static this`) 
that uses `wndclassName`? If so, you might be hitting issue 
18412.


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

If you don't have a static constructor, it might be a different 
bug. In that case, please provide complete code so that we can 
get to the bottom of it.


I have a static constructor that uses wndclassName to register 
the window class... at the top of the file.


I think that's the bug.

[Issue 5502] More handy ways to create associative arrays

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #5 from Seb  ---

> import std.array: AAFromKeys;
> void main() {
>bool[dchar] dcharSet = AAFromKeys("ABCD", true);
> }

This is already easily possible today:

---
assocArray("ABCD".zip(true.repeat)).writeln;
---

https://run.dlang.io/is/7j1ObE

We could add another overload to assocArray that accepts two arguments: values
+ keys

-> PR: https://github.com/dlang/phobos/pull/6155

--

Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests

[Walter Bright via Digitalmars-d]

On 2/8/2018 7:06 PM, Timothee Cour wrote:

/"EOC
This is a multi-line
heredoc comment allowing
/+ documented unittests containing nesting comments +/
and weird urls like https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
EOS"/


There isn't any commenting scheme that won't trip you up with certain characters 
in the comments. I don't see a compelling case for adding another kind of comment.


Vladimir's suggestion to use %2B instead of + seems to resolve this adequately.

[Issue 9976] Needlessly large instantiation depth in std.typetuple algorithms

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

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

Seb  changed:

   What|Removed |Added

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

--

Re: Getting a reference to an immutable string

[ag0aep6g via Digitalmars-d-learn]

On 02/10/2018 11:46 PM, David Zhang wrote:

This is what I'm talking about:

void createWindow( ... ) {

     assert( wndclassName.ptr ); //This fails

     HWND hwnd = CreateWindowW(
     wndclassName.ptr, //This too
     null,
     0,
     CW_USEDEFAULT, CW_USEDEFAULT,
     CW_USEDEFAULT, CW_USEDEFAULT,
     null,
     null,
     null,
     null
     );
}

wstring wndclassName = "wndclass_name"w;


That's not enough code to reproduce the issue. This works as far as I see:


import core.sys.windows.windef: HWND;
import core.sys.windows.winuser: CreateWindowW, CW_USEDEFAULT;

void main()
{
assert( wndclassName.ptr );

HWND hwnd = CreateWindowW(
wndclassName.ptr,
null,
0,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
null,
null,
null,
null
);
}

wstring wndclassName = "wndclass_name"w;


But there is a recent regression on Windows that might be related. Do 
you also have a static constructor (`static this`) that uses 
`wndclassName`? If so, you might be hitting issue 18412.


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

If you don't have a static constructor, it might be a different bug. In 
that case, please provide complete code so that we can get to the bottom 
of it.

[Issue 10379] std.string.translate (and others) for a Range of characters

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #3 from Seb  ---
2.079 will ship with substitute:

https://dlang.org/changelog/pending.html#std-algorithm-iteration-substitute

It doesn't use an internal table and is fully lazy and @nogc.
Its generic and works with any kind of range (+strings) and single chars.

Moreover, there's tr and translate in std.string:

https://dlang.org/phobos/std_string.html#.tr
https://dlang.org/phobos/std_string.html#.translate

--

Re: Getting a reference to an immutable string

[David Zhang via Digitalmars-d-learn]

Building with Visual Studio seems to be fine. This isn't an 
OptLink issue, is it?

Re: Getting a reference to an immutable string

[David Zhang via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 22:36:41 UTC, ag0aep6g wrote:

On 02/10/2018 11:26 PM, David Zhang wrote:
I've got an immutable string declared in module scope, and I 
attempted to get a pointer to its characters through both 
[0] and str.ptr. However, it appears to me that the string 
is behaving like a manifest constant, in that the pointer is 
null.


The language reference indicates that it has a location in 
memory and thus has a pointer.


So, my question is thus: Is this a bug in DMD, or is this just 
something I missed?


The pointer should not be null, even when `str` is a manifest 
constant. But without code it's impossible to say if you're 
hitting a compiler bug or if you're doing something wrong.


Ah, yeah.

It appears to occur only when compiled in x86 mode.

This is what I'm talking about:

void createWindow( ... ) {

assert( wndclassName.ptr ); //This fails

HWND hwnd = CreateWindowW(
wndclassName.ptr, //This too
null,
0,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
null,
null,
null,
null
);
}

wstring wndclassName = "wndclass_name"w;

Re: Getting a reference to an immutable string

[ag0aep6g via Digitalmars-d-learn]

On 02/10/2018 11:26 PM, David Zhang wrote:
I've got an immutable string declared in module scope, and I attempted 
to get a pointer to its characters through both [0] and str.ptr. 
However, it appears to me that the string is behaving like a manifest 
constant, in that the pointer is null.


The language reference indicates that it has a location in memory and 
thus has a pointer.


So, my question is thus: Is this a bug in DMD, or is this just something 
I missed?


The pointer should not be null, even when `str` is a manifest constant. 
But without code it's impossible to say if you're hitting a compiler bug 
or if you're doing something wrong.

Re: A betterC base

[Dmitry Olshansky via Digitalmars-d]

On Saturday, 10 February 2018 at 18:40:43 UTC, Andrei 
Alexandrescu wrote:

On 2/10/18 10:14 AM, Dmitry Olshansky wrote:
On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright 
wrote:
Of course, the issue can get more complex. GC uses 3x the 
memory of RC,


  I’ve seen figures of about x2 but that was in an old paper 
on Boehm GC.


This is the classic reference: 
https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf. 
Executive review in the abstract: "With only three times as 
much memory, the collector runs on average 17% slower than 
explicit memory management.


Reading the whole paper is a tad more important:

On particular “manual” memory management is aided by precompted 
trace of lifetimes w/o any bookkeeping performed by the 
application.


Citation #1:
Oracular memory management framework. As Figure 1(a) shows, it 
first executes the Java pro- gram to calculate object lifetimes 
and generate the program heap trace. The system processes the 
program heap trace uses the Mer- lin algorithm to compute object 
reachability times and generate the reachability-based oracle. 
[...] Using these oracles, the oracular memory manager executes 
the program as shown in Figure 1(b), allocating objects using 
calls to malloc and invoking free on objects when directed by the 
oracle


Plus - single threaded only... (e.g. parallel GC is a thing)

Citation #2:
In the experiments we present here, we assume a single-processor 
environment and disable atomic operations both for Jikes RVM and 
for the Lea allocator. In a multithreaded environment, most 
thread- safe memory allocators also require at least one atomic 
operation for every call to malloc and free: a test-and-set 
operation for lock-based allocator...


However, with only twice as much memory, garbage collection 
degrades performance by nearly 70%. When physical memory is 
scarce, paging causes garbage collection to run an order of 
magnitude slower than explicit memory management." -- Andrei

[Issue 11475] std.algorithm.multiSort.release or similar

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---

This works since 2.072:

Up to  2.071.2: Failure with output: onlineapp.d(12): Error: no property
'release' for type 'void'
Since  2.072.2: Success with output: [Point(0, 0), Point(0, 1), Point(0,
2), Point(5, 5)]



---
import std.algorithm, std.stdio;

void main()
{
static struct Point
{
int x, y;
}

auto pts1 = [Point(0, 0), Point(5, 5), Point(0, 1), Point(0, 2)];

multiSort!("a.x < b.x", "a.y < b.y",
SwapStrategy.unstable)(pts1).release.writeln;
}
---


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

--

[Issue 11475] std.algorithm.multiSort.release or similar

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

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

Seb  changed:

   What|Removed |Added

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

--

[Issue 11555] std.algorithm.reverse should return the just-reversed range

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #6 from Seb  ---
What's the status of this?

The way I see it:

1) There's now retro
2) reverse should have been in std.array
3) The naming is bad (reverse and reversed would have been better)

But I doubt we can change any of this, except for moving reverse to std.array
and doing a public import in std.algorithm. Thoughts?

--

Getting a reference to an immutable string

[David Zhang via Digitalmars-d-learn]

Hi,

I've got an immutable string declared in module scope, and I 
attempted to get a pointer to its characters through both [0] 
and str.ptr. However, it appears to me that the string is 
behaving like a manifest constant, in that the pointer is null.


The language reference indicates that it has a location in memory 
and thus has a pointer.


So, my question is thus: Is this a bug in DMD, or is this just 
something I missed?


Thanks

David

Re: Which language futures make D overcompicated?

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 10, 2018 20:57:44 John Gabriele via Digitalmars-d 
wrote:
> On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele
>
> wrote:
> > {snip} It's not niche at all, it just doesn't have hoards of
> > users. D is well-positioned to be hugely popular, but I think
> > to succeed its leadership needs to be willing to fix things
> > they want to fix and not worry about breaking backcompat.
>
> Augh! "hordes", not "hoards".

Clearly, someone is hoarding our hordes, which is why we don't see enough of
them. ;)

- Jonathan M Davis

[Issue 12216] Overloading templates using alias

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
This is going to be tough because some templates are written like this:


foo()
if (a)

foo()
if (!a)


There overloading is rather hard.

However, the following trick should always work:

---
bool isSorted(alias less = "a < b", Range)(Range r)
{
import std.algorithm : isSortedImpl = isSorted;

static if (isStaticArray!Range)
{
return isSortedImpl!less(r[]);
}
else
{
return isSortedImpl!less(r[]);
}
}
---

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

Though nowadays this isn't even necessary for isSorted.

--

[Issue 10670] std.algorithm.reduce: no-seed initialization wrong design

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #8 from Seb  ---
fold has been introduced as deprecating reduce wasn't an option.
I don't think we can modify or deprecate the behavior of reduce, so I'm
inclined to close this as WONTFIX.

--

[Issue 18086] BigInt DivMod

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

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

--- Comment #4 from Paul D. Anderson  ---
(In reply to Seb from comment #3)
> Works fine for me: 
> 
> https://run.dlang.io/is/r07zHf
> 
> (setting this to RESOLVED FIXED as the PR has been merged)
> 
> Are you sure you are using nightly?

Sorry, my mistake.

--

[Issue 12335] std.algorithm.skipOver should support multiple args like startsWith

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
PR https://github.com/dlang/phobos/pull/6143

--

[Issue 10959] std.algorithm.remove is highly bug-prone

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #14 from Seb  ---
A PR to fix the landmines - https://github.com/dlang/phobos/pull/6154

It's probably too late to rename `remove` :/

--

[Issue 12086] std.algorithm.remove + range of indices produces wrong results

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

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

Seb  changed:

   What|Removed |Added

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

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

--

Re: A betterC base

[Walter Bright via Digitalmars-d]

On 2/10/2018 7:14 AM, Dmitry Olshansky wrote:

RC is a form of GC.


Pedantically, yes. But common usage regards the two as disjoint, and it's 
inconvenient to treat RC as a subset of GC when discussing tradeoffs between the 
two. Nobody bothers with s/GC/GC excluding RC/.

Re: dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, February 10, 2018 21:10:28 Joakim via Digitalmars-d-announce 
wrote:
> On Saturday, 10 February 2018 at 18:57:53 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, February 10, 2018 16:14:41 Jacob Carlborg via
> >
> > Digitalmars-d- announce wrote:
> >> On 2018-02-09 22:15, Jonathan M Davis wrote:
> >> > [...]
> >>
> >> This is great news! Have you run any benchmarks to see how it
> >> performs?
> >
> > Kind of. I did some benchmarking to see if some code changes
> > would improve performance, but I haven't tried benchmarking it
> > against any other XML libraries. That would take a fair bit of
> > time and effort, and IMHO, that would be better spent finishing
> > the library first. Also, ldc's latest release is only up to dmd
> > 2.077.1, and dxml needs an improvement that got added to
> > byCodeUnit in 2.078.0, so any benchmarking that wants to do
> > something like compare dxml with a C/C++ parsing library while
> > taking the optimizer out of the equation isn't going to work
> > yet unless I fork byCodeUnit for dxml until we get another
> > release of ldc.
>
> ldc master uses the latest 2.078.2 frontend and stdlib, you could
> always build it yourself:
>
> https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L54
> https://wiki.dlang.org/Building_LDC_from_source

That's good to know. Thanks.

If I get to the point where I want to do more benchmarking before ldc does
another release, I'll build it myself, though depending on when I reach that
point and when ldc plans to do another release, it may or may not end up
being necessary.

- Jonathan M Davis

Re: dxml 0.1.0 released

[Joakim via Digitalmars-d-announce]

On Saturday, 10 February 2018 at 18:57:53 UTC, Jonathan M Davis 
wrote:
On Saturday, February 10, 2018 16:14:41 Jacob Carlborg via 
Digitalmars-d- announce wrote:

On 2018-02-09 22:15, Jonathan M Davis wrote:
> [...]
This is great news! Have you run any benchmarks to see how it 
performs?


Kind of. I did some benchmarking to see if some code changes 
would improve performance, but I haven't tried benchmarking it 
against any other XML libraries. That would take a fair bit of 
time and effort, and IMHO, that would be better spent finishing 
the library first. Also, ldc's latest release is only up to dmd 
2.077.1, and dxml needs an improvement that got added to 
byCodeUnit in 2.078.0, so any benchmarking that wants to do 
something like compare dxml with a C/C++ parsing library while 
taking the optimizer out of the equation isn't going to work 
yet unless I fork byCodeUnit for dxml until we get another 
release of ldc.


ldc master uses the latest 2.078.2 frontend and stdlib, you could 
always build it yourself:


https://github.com/ldc-developers/ldc/blob/master/CMakeLists.txt#L54
https://wiki.dlang.org/Building_LDC_from_source

[Issue 11084] std.algorithm.scan

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

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

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

https://github.com/dlang/phobos/commit/4775a5e3576843b58f99739d1a9141c810656679
Fix Issue 11084 - std.algorithm.scan

https://github.com/dlang/phobos/commit/ae2219c562912e18d0f33fe641adadd18bb62e18
Merge pull request #6153 from wilzbach/mention-scan

Fix Issue 11084 - Mention scan in cumulativeFold
merged-on-behalf-of: Jack Stouffer 

--

Re: dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, February 10, 2018 19:53:48 Jesse Phillips via Digitalmars-d-
announce wrote:
> On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis
>
> wrote:
> > Hopefully, the documentation is clear enough, but obviously,
> > I'm not the best judge of that. So, have at it.
> >
> > Documentation: http://jmdavisprog.com/docs/dxml/0.1.0/
> > Github: https://github.com/jmdavis/dxml
> > Dub: http://code.dlang.org/packages/dxml
> >
> > - Jonathan M Davis
>
> This looks so nice.
>
> I can understand the concerns of the DTD, and it doesn't look
> like you needed to do anything special for namespaces with this
> parser.

I confess that I haven't looked into namespaces in detail, but from what I
understand about them, I don't see any reason to do anything beyond treating
them as part of the name. If the application wants to do something special
with them, then it's free to do so. Key goals of this parser were to make it
fast and simple to use for the typical use case. As much as possible, I'd
like to keep the complicated stuff out of it.

Personally, I see XML only as data just like JSON is only data, and I think
that the complications in the XML spec come from trying to treat it as more
than that.

I had originally intended to provide at least minimal DTD support but leave
most of it to some kind of helper functionality (e.g. have a helper function
which took the DTD data and then validated the rest of the XML using it).
However, as I got farther along, it became clear that that wasn't going to
work without giving up on being able to just slice the input, and I wasn't
willing to give up on that, especially when I don't see handling the DTD as
valuable for anything but dealing with overly complicated XML that is
outside of the programmer's control or to simply be able to say that I
completely implemented the XML spec.

Slicing is part of why parsers written in D should tend to be inherently
fast in comparison to those written in languages like C++, and I want to
take advantage of that. In principle, something like an XML parser should be
able to be a showcase for why D is great. Tango's was, but Phobos' hasn't
been, and I'd like for dxml to be able to be that regardless of whether it
eventually replaces std.xml or not.

- Jonathan M Davis

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Saturday, 10 February 2018 at 20:55:00 UTC, John Gabriele 
wrote:


{snip} It's not niche at all, it just doesn't have hoards of 
users. D is well-positioned to be hugely popular, but I think 
to succeed its leadership needs to be willing to fix things 
they want to fix and not worry about breaking backcompat.


Augh! "hordes", not "hoards".

Re: Which language futures make D overcompicated?

[John Gabriele via Digitalmars-d]

On Saturday, 10 February 2018 at 12:44:14 UTC, rjframe wrote:

On Fri, 09 Feb 2018 22:36:19 +, Ralph Doncaster wrote:

Frankly, I think it is doomed to be a niche-use language.  
While many more things were done right compared to C++, too 
many things were done wrong and there doesn't seem to be 
interest in breaking backward compatibility to excise them 
from D.


Yes.

If the current "let's get C++ programmers to like us" stuff 
continues, some of these problems will have to be fixed. I'm 
expecting C++20 to be a nice language for new projects, where 
you can ignore a lot of the blech (though not quite enough of 
it), and moving to C++20 will be easier than moving to D. The 
ROI just won't be there for most people (for many, it doesn't 
seem to be there today...).


I also agree. One of the prime benefits of a language with a 
smaller community is that you can make it _better_ *faster*, 
breaking backcompat more easily and more often, and getting a 
better language in the process. After all, if its users wanted 
something slow to evolve, they'd be using one of the 
industry-accepted behemoths.


I'm not sure that being a niche language is a bad thing; if we 
just say, "this is D; if you like it come and use it, come help 
make it better, but if it doesn't help you -- that's OK. There 
are other languages too" -- we may have more freedom to explore 
what D can do best. I've done compile- time stuff in D I would 
never have even considered attempting with C++ - and I haven't 
done nearly as much as others here. I don't think we've really 
explored the fullness of the language yet, and I wonder if 
that's only going to be possible if we quit comparing ourselves 
so much to C++.


I don't think D is designed to be a niche language. It's a 
general purpose language, open source with multiple 
implementations, solid engineering, and even has good-looking 
syntax. It's not niche at all, it just doesn't have hoards of 
users. D is well-positioned to be hugely popular, but I think to 
succeed its leadership needs to be willing to fix things they 
want to fix and not worry about breaking backcompat.

Re: Which language futures make D overcompicated?

[Jon Degenhardt via Digitalmars-d]

On Friday, 9 February 2018 at 07:54:49 UTC, Suliman wrote:

Which language futures by your opinion make D harder?


For me, one of the attractive qualities of D is its relative 
simplicity. Key comparison points are C++, Scala, and Python. 
Python being the simplest, then D, not far off, with Scala and 
C++ being more complex. Entirely subjective, not measured in any 
empirical way.


That said, a couple of D constructs that I personally find 
increases friction:


* Static arrays aren't not ranges. I continually forget to slice 
them when I want to use them as ranges. The compiler errors are 
often complex template instantiation failure messages.


* Template instantiation failures - It takes longer than I'd like 
to figure out why a template failed to instantiate. This is 
especially true when there are multiple overloads, each with 
multiple template constraints.


* Auto-decoding - Mentioned by multiple people. It's mainly an 
issue after you've decided you need to avoid it. Figuring out how 
out to utilize Phobos routines without having them engage 
auto-decoding on your behalf is challenging.


--Jon

[Issue 11084] std.algorithm.scan

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

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

--- Comment #5 from Seb  ---
PR to reference alternatives names: https://github.com/dlang/phobos/pull/6153

--

[Issue 11084] std.algorithm.scan

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
There's cumulativeFold since 2.072:

---
import std.algorithm, std.range, std.stdio;

void main()
{
   10.iota.cumulativeFold!((a, b) =>  a + b).writeln;
}
---

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

--

[Issue 11891] Ddoc should generate index table

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
Status quo:

(1) JavaScript hack to generate a "quickIndex"

However because (1) looked too ugly, a manual BOOKMARK table has been added to
most modules. Generating a grouped BOOKMARK table automatically is really hard
though.

FWIW ddox and adrdox can generate index tables out of the box.

I'm not sure if anyone plans to actively develop Ddoc. Migration to Ddox for
dlang.org is WIP though it might never happen.

--

[Issue 12592] std.algorithm.keep?

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
We have group and filter, e.g.

---
import std.stdio;
void main() {
import std.algorithm;
immutable data = [10, 3, 2, 3, 4, 10];
assert(data.dup.sort.release.group.map!(a => a[0]).equal([2, 3, 4, 10]));
}
---

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

Closing as WORKSFORME. Plese reopen if you feel that filter and group don't
work for or you have more arguments or examples.

--

[Issue 10493] ICE with -inline, depending on order of source files

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
Compiles fine for me with 2.079

--

[Issue 11826] [ctfe] CTFE fails to issue diagnostic for unsupported feature of closures

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #6 from Seb  ---


2.062   to 2.066.0: Failure with output: --- killed by signal 11
Since  2.067.1: Success with output: [Tuple!(int, int)(1, 10), Tuple!(int,
int)(1, 20), Tuple!(int, int)(1, 30), Tuple!(int, int)(2, 10), Tuple!(int,
int)(2, 20), Tuple!(int, int)(2, 30), Tuple!(int, int)(3, 10), Tuple!(int,
int)(3, 20), Tuple!(int, int)(3, 30)]


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

--

[Issue 8750] ICE when using any and all as a template condition

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #3 from Seb  ---
Fixed in 2.064:

2.062   to 2.063  : Status -6 with output: dmd: mangle.c:100: char*
mangle(Declaration*, bool): Assertion `fd && fd->inferRetType' failed.
   2.064  : Failure with output:
-
onlineapp.d(9): Error: template std.algorithm.all does not match any function
template declaration. Candidates are:

--

[Issue 10709] reduce 1-function + no seed, wrong type inference

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #4 from Seb  ---
Since  2.067.1: Success with output:
-
3
Tuple!(double, double)(3, 3)
-


https://run.dlang.io/is/6DV7gi

--

[Issue 13591] [Enh] add std.algorithm.reinterpret

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
> Currently, it is clumsy to change the type of an Element in a pipeline

Well, the status quo for whole elements

a.b.pipe!(a => cast(T)).c.d

And for elements:

a.b.map!(a => cast(T)).c.d

Or is this just a request to generalize std.exception.assumeUnique into
assume!XYZ, but being @safe for all its generalizations?

--

Re: dxml 0.1.0 released

[Jesse Phillips via Digitalmars-d-announce]

On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis 
wrote:


Hopefully, the documentation is clear enough, but obviously, 
I'm not the best judge of that. So, have at it.


Documentation: http://jmdavisprog.com/docs/dxml/0.1.0/
Github: https://github.com/jmdavis/dxml
Dub: http://code.dlang.org/packages/dxml

- Jonathan M Davis


This looks so nice.

I can understand the concerns of the DTD, and it doesn't look 
like you needed to do anything special for namespaces with this 
parser.

[Issue 10009] AA.byKey/byValue should be bidirectional ranges

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

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||greensunn...@gmail.com
Summary|foreach_reverse and |AA.byKey/byValue should be
   |AA.byKey/byValue|bidirectional ranges

--- Comment #31 from Seb  ---
> That leaves this with just the unlikely enhancement, of making byKey/byValue 
> into bidirectional ranges.

Renamed the title to match this.

--

[Issue 13793] @nogc std.algorithm.count(std.range.only)

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
Works in 2.078, It has been fixed in 2.069

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

--

Re: A betterC base

[Paulo Pinto via Digitalmars-d]

On Saturday, 10 February 2018 at 19:22:51 UTC, Jonathan M Davis 
wrote:
On Saturday, February 10, 2018 14:06:09 Timon Gehr via 
Digitalmars-d wrote:

On 08.02.2018 16:55, JN wrote:
> On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe 
> wrote:
>> Garbage collection has proved to be a smashing success in 
>> the industry, providing productivity and memory-safety to 
>> programmers of all skill levels.

>
> Citation needed on how garbage collection has been a 
> smashing success based on its merits rather than the merits 
> of the languages that use garbage collection. Python was 
> also a smashing success, but it doesn't use a garbage 
> collector in it's default implementation (CPython). Unless 
> you mean garbage collection as in "not manual memory 
> management"? ...


Even if "garbage collection" is taken to mean "collecting 
garbage", reference counting is garbage collection. Referring 
to RC as not GC makes no sense at all and was probably only 
invented because some people want to think that RC is good but 
GC is bad, being too lazy to say "tracing GC".


Except that RC and what folks typically mean what they talk 
about GC are fundamentally different. Yes, they both 
automatically free memory for you, but one is deterministic, 
whereas the other involves periodically running a collection to 
find memory that can be freed. So, yes, in a sense, RC is a 
form of GC, but they're very different beasts.


- Jonathan M Davis


People like to think that RC is deterministic.

First of all, unless they are atomic, there are no guarantees of 
pause time during locking on counter access.


Second, Herb Sutter has a great CppCon talk about 
non-deterministic releases, with the possibility of stack 
overflow, in complex datastructures.


Herb Sutter “Leak-Freedom in C++... By Default.”

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

Re: A betterC base

[Jonathan M Davis via Digitalmars-d]

On Saturday, February 10, 2018 14:06:09 Timon Gehr via Digitalmars-d wrote:
> On 08.02.2018 16:55, JN wrote:
> > On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
> >> Garbage collection has proved to be a smashing success in the
> >> industry, providing productivity and memory-safety to programmers of
> >> all skill levels.
> >
> > Citation needed on how garbage collection has been a smashing success
> > based on its merits rather than the merits of the languages that use
> > garbage collection. Python was also a smashing success, but it doesn't
> > use a garbage collector in it's default implementation (CPython). Unless
> > you mean garbage collection as in "not manual memory management"? ...
>
> Even if "garbage collection" is taken to mean "collecting garbage",
> reference counting is garbage collection. Referring to RC as not GC
> makes no sense at all and was probably only invented because some people
> want to think that RC is good but GC is bad, being too lazy to say
> "tracing GC".

Except that RC and what folks typically mean what they talk about GC are
fundamentally different. Yes, they both automatically free memory for you,
but one is deterministic, whereas the other involves periodically running a
collection to find memory that can be freed. So, yes, in a sense, RC is a
form of GC, but they're very different beasts.

- Jonathan M Davis

[Issue 14492] Deprecate scope for allocating classes on the stack

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

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

--- Comment #8 from Jonathan M Davis  ---
(In reply to Iain Buclaw from comment #7)
> DDMD still depends on this heavily.  For now scope class is going nowhere,
> if the idea of deprecating it hasn't already been completely reversed.

If I understand DIP 1000 correctly, I think that the original meaning of scope
on class reference is basically becoming an optimization done with scope rather
than the direct purpose of the feature, and the work with DIP 1000 should in
theory make it @safe. So, if DIP 1000 is accepted (and I assume it will be once
it's ready, since it's Walter who's doing it, and he's spent a lot of time on
it), then scope on class references is here to stay.

--

Re: dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, February 10, 2018 10:27:42 Stefan via Digitalmars-d-announce 
wrote:
> great work, Jonathan. Thank you.
> We were missing xml for a long time and did so many hacks just to
> get xml somehow parsed.

LOL. Actually, one of the helper functions in std.datetime.timezone that has
to deal with xml does it via hacks, because the XML in question was fairly
simple, and I didn't want to deal with std.xml.

If dxml does end up going through the Phobo review process and eventually
ends up in Phobos, I'll have to change that code so that it uses dxml
instead of the hacks.

- Jonathan M Davis

Re: dxml 0.1.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Saturday, February 10, 2018 12:04:48 Seb via Digitalmars-d-announce 
wrote:
> On Friday, 9 February 2018 at 21:15:33 UTC, Jonathan M Davis
>
> wrote:
> > I have multiple projects that need an XML parser, and
> > std_experimental_xml is clearly going nowhere, with the guy who
> > wrote it having disappeared into the ether, so I decided to
> > break down and write one. I've kind of wanted to for years, but
> > I didn't want to spend the time on it. However, sometime last
> > year I finally decided that I had to, and it's been what I've
> > been working on in my free time for a while now. And it's
> > finally reached the point when it makes sense to release it -
> > hence this post.
> >
> > [...]
>
> FWIW we recently forked the experimental.xml repo to
> dlang-community:
>
> https://github.com/dlang-community/experimental.xml
>
> So PRs etc can be merged easily.
> But yeah it's not moving anywhere atm :/

Yeah, I got some e-mails about that the other day, since I had some open
issues and PRs on it, and IIRC github was telling me that you'd migrated
some of that over, but unless someone decides that they want to take up the
torch on it, it seems pretty dead. I assume that the guy who did it simply
got too busy with school once GSoC ended and then never got back to it even
when he did have time. If he were serious about finishing it and being an
active part of the D community, he would have at least looked at some the
PRs on the project, but he's been completely silent for quite a while now.
So, I guess he moved on. I was able to use it on one of my projects by
making some local changes and by working around some bugs, but it clearly
needs work that it's not getting.

I had some rather specific ideas about what I wanted to do with an XML
parser though and didn't want to spend the time trying to decipher what he'd
done and morph it into something more like what I wanted, so I just started
from scratch.

- Jonathan M Davis

Re: A betterC base

[Andrei Alexandrescu via Digitalmars-d]

On 2/10/18 10:14 AM, Dmitry Olshansky wrote:

On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote:

Of course, the issue can get more complex. GC uses 3x the memory of RC,


  I’ve seen figures of about x2 but that was in an old paper on Boehm GC.


This is the classic reference: 
https://people.cs.umass.edu/~emery/pubs/gcvsmalloc.pdf. Executive review 
in the abstract: "With only three times as much memory, the collector 
runs on average 17% slower than explicit memory management. However, 
with only twice as much memory, garbage collection degrades performance 
by nearly 70%. When physical memory is scarce, paging causes garbage 
collection to run an order of magnitude slower than explicit memory 
management." -- Andrei

Re: Fixed size array initialization

[Seb via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 15:54:03 UTC, rumbu wrote:

On Saturday, 10 February 2018 at 14:55:49 UTC, b2.temp wrote:

On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote:


In this case, it there any way to be sure that I declared all 
the elements I intended? Obviously, without counting them by 
hand.


At the level of the library use a template.


Sorry, but I don't get it. Can you elaborate, please?


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

Re: Fixed size array initialization

[rumbu via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 14:55:49 UTC, b2.temp wrote:

On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote:


In this case, it there any way to be sure that I declared all 
the elements I intended? Obviously, without counting them by 
hand.


At the level of the library use a template.


Sorry, but I don't get it. Can you elaborate, please?

This is the array in question: 
https://github.com/rumbu13/decimal/blob/master/src/decimal/integrals.d#L2072


First time, I tried to use mixins to generate the array, in order 
to avoid writing the same thing again and again. The mixin 
solution was nice until the compiler served me a nice Out of 
Memory error, that's why I finally used a hand-written array.




At the level of the compiler: no. Not only not all elements are 
required but they also don't need to be declared in order 
(static array initialization, like in the example beyond).


It would be possible to put a compiler warning but warnings are 
not in the D philosophy (one consequence is that many people, 
like me use -de all the time, making a possible warning not 
compatible with the legit uses of the "partial array 
initialization").


By the way i said i did change the compiler. Actually i even 
captured the session to promote my IDE: 
http://sendvid.com/c00x7nps.

Re: dxml 0.1.0 released

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-02-09 22:15, Jonathan M Davis wrote:


Currently, dxml contains only a range-based StAX / pull parser and related
helper functions, but the plan is to add a DOM parser as well as two writers
- one which is the writer equivalent of a StaX parser, and one which is
DOM-based. However, in theory, the StAX parser is complete and quite useable
as-is - though I expect that I'll be adding more helper functions to make it
easier to use, and if you find that you're doing a particular operation with
it frequently and that that operation is overly verbose, please point it out
so that maybe a helper function can be added to improve that use case - e.g.


This is great news! Have you run any benchmarks to see how it performs?

--
/Jacob Carlborg

Re: A betterC base

[Dmitry Olshansky via Digitalmars-d]

On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote:

On 2/9/2018 1:14 AM, meppl wrote:
let's say python is supposed to offer slow execution. So, 
python doesn't prove reference counting is fast (even if it is 
possible in theory). D on the other hand provides binaries who 
are expected to execute fast.


I believe it has been shown (sorry, no reference) that GC is 
faster in aggregate time, and RC is perceived faster because it 
doesn't have pauses.


RC is a form of GC. Also tracing GCs with pause times under 1ms 
are in production for seceral languages now.




This makes GC better for batch jobs, and RC better for 
interactive code.


Yes GCs with lower pause time sacrifices throughput for low 
latency. RC included.




Of course, the issue can get more complex. GC uses 3x the 
memory of RC,


 I’ve seen figures of about x2 but that was in an old paper on 
Boehm GC.



and so you can get extra slowdowns from swapping


Oh come on... anything touching swap is usually frozen these 
days. Plus heap size is usually statically bounded for GC 
languages, choosen not to grow beyond ram.



and cache misses.

Re: Which language futures make D overcompicated?

[Timon Gehr via Digitalmars-d]

On 10.02.2018 14:05, Mark wrote:

On Saturday, 10 February 2018 at 12:35:39 UTC, Timon Gehr wrote:
So as expected, the difference is that for parametrically polymorphic 
functions, the type T /does not need to be known at compile time/.


According to this definition C++ doesn't support parametric polymorphism 
either, does it?


It does not. C++ templates are a kind of restricted hygienic macro 
system, similar to D templates. It is however common for programmers to 
apply PL-theoretical terms in a somewhat sloppy way, e.g. here: 
https://rosettacode.org/wiki/Parametric_polymorphism


(Fun fact: it is actually only called "polymorphism". "Parametric" is 
added to distinguish the term from its usage related to virtual method 
calls in object-oriented programming languages.)


To be fair, templates quite successfully simulate parametric 
polymorphism for a large subset of its use cases and the compile-time 
code generation aspect can be very useful too.



Are there any C-style languages that allow that?



C#. Also, to some extent, Java.

Re: Fixed size array initialization

[b2.temp--- via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote:

On Saturday, 10 February 2018 at 12:28:16 UTC, b2.temp wrote:

On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote:
I know that according to language spec 
(https://dlang.org/spec/arrays.html#static-init-static) you 
can skip declaring all your elements in a fixed size array.


I'm just recovering from a bug which took me one day to 
discover because of this.


I have a large static initialized array, let's say int[155], 
and I forgot to declare the last element:


int[155] myarray = [
  a,
  b,
  c,
  ...
  //forgot to declare the 155th element
];

I took for granted that the compiler will warn me about the 
fact that my number of elements doesn't match the array 
declaration but I was wrong.


Does it worth to fill an enhancement on this, or this is 
intended behavior?


I used to agree 
(https://issues.dlang.org/show_bug.cgi?id=17341) and even 
patched the compiler

to emit a deprecation in this case. Then
i discovered that druntime for example relies on this.

The classic use case is to init a LUT where only a few 
elements need a non-default value, for example:


```
bool[char.max] lut = [10:true, 13:true, 9: true];
assert(!lut[46]);
assert(lut[9]);
```

which can be useful.


In this case, it there any way to be sure that I declared all 
the elements I intended? Obviously, without counting them by 
hand.


At the level of the library use a template.

At the level of the compiler: no. Not only not all elements are 
required but they also don't need to be declared in order (static 
array initialization, like in the example beyond).


It would be possible to put a compiler warning but warnings are 
not in the D philosophy (one consequence is that many people, 
like me use -de all the time, making a possible warning not 
compatible with the legit uses of the "partial array 
initialization").


By the way i said i did change the compiler. Actually i even 
captured the session to promote my IDE: 
http://sendvid.com/c00x7nps.

Re: Fixed size array initialization

[rumbu via Digitalmars-d-learn]

On Saturday, 10 February 2018 at 12:28:16 UTC, b2.temp wrote:

On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote:
I know that according to language spec 
(https://dlang.org/spec/arrays.html#static-init-static) you 
can skip declaring all your elements in a fixed size array.


I'm just recovering from a bug which took me one day to 
discover because of this.


I have a large static initialized array, let's say int[155], 
and I forgot to declare the last element:


int[155] myarray = [
  a,
  b,
  c,
  ...
  //forgot to declare the 155th element
];

I took for granted that the compiler will warn me about the 
fact that my number of elements doesn't match the array 
declaration but I was wrong.


Does it worth to fill an enhancement on this, or this is 
intended behavior?


I used to agree 
(https://issues.dlang.org/show_bug.cgi?id=17341) and even 
patched the compiler to emit a deprecation in this case. Then i 
discovered that druntime for example relies on this.


The classic use case is to init a LUT where only a few elements 
need a non-default value, for example:


```
bool[char.max] lut = [10:true, 13:true, 9: true];
assert(!lut[46]);
assert(lut[9]);
```

which can be useful.


In this case, it there any way to be sure that I declared all the 
elements I intended? Obviously, without counting them by hand.

[Issue 14492] Deprecate scope for allocating classes on the stack

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

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #7 from Iain Buclaw  ---
DDMD still depends on this heavily.  For now scope class is going nowhere, if
the idea of deprecating it hasn't already been completely reversed.

--

[Issue 14491] Deprecate overriding without override

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
This has been an error since 2.072.

--

[Issue 14489] Deprecate Floating point NCEG operators

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

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

Iain Buclaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ibuc...@gdcproject.org
 Resolution|--- |FIXED

--- Comment #1 from Iain Buclaw  ---
This has been removed from the spec, and is currently and error in the
compiler.

Not aware of any "gone" status, but that's outside scope of original issue.

--

[Issue 14490] Deprecate .sort and .reverse properties for arrays

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

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
Gone in 2.075

--

[Issue 5323] std.math: struct FloatingPointControl, duplicate code and assumes X86

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

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

--- Comment #6 from Iain Buclaw  ---
Has been improved somewhat by:

https://github.com/dlang/phobos/pull/4272
https://github.com/dlang/phobos/pull/5769

--

Re: A betterC base

[Dukc via Digitalmars-d]

On Friday, 9 February 2018 at 21:24:14 UTC, Walter Bright wrote:
Of course, the issue can get more complex. GC uses 3x the 
memory of RC, and so you can get extra slowdowns from swapping 
and cache misses.


Is the total memory consumption tripled, or only the extra memory 
used for tracking allocations?

Re: Which language futures make D overcompicated?

[Bo via Digitalmars-d]

On Friday, 9 February 2018 at 23:01:44 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 9 February 2018 at 20:49:24 UTC, Meta wrote:
was a complicated language, 99 of them would say no. If you 
ask 100 Python programmers, 99 would probably say yes.


Yes, but objectively speaking I'd say modern Python is more 
complicated than C++ and D.


What Python got right is that you don't have to deal with the 
complicated stuff unless you are hellbent on dealing with it. 
Python affords a very smooth incremental learning curve, but it 
is still a long learning curve...


^ This ...

I am seeing some responses that a language that is not loaded 
with all the options is not really real language. Yet, those 
languages are used for productivity all over the world.


Go is horrible limited and yet loved by many. And many really 
push the boundaries very far. But why do Python, PHP, Ruby, Go 
and others rank so high. Its because they are designed with a 
easy learning curve and documentation to match this curve.


D has the issue its designed to trow people into the deep end of 
the pool. Reading the responses on the basic nitpicking issues 
with D ( that i posted here ), you can tell that people "do not 
get it". Its small issues but a lot of small issues simply 
increase complexity. One mole in a garden is not a issue and can 
be overlooked. A hundred and people prefer the garden next door.


D will never be a language that draws in a lot of people from 
scripting languages like Python, PHP, Ruby simply because its 
clearly not designed with this mindset. It also does not help how 
much strange code decisions have been made in the past, that 
result in awkward library issues.


The problem is most languages allow you to program 80 to 90% of 
the task with eases.


D is focused on providing those extra 10 a 20% but in doing so 
the language has gotten complex, the library filled with years of 
scruff and because it focused on that extra 20%, it only draws in 
a selective crowd that keeps pushing more and more into that 
boundary. And that same crowd is not focused on leaving C++ any 
time soon, as C++ keeps evolving and improving. Anybody really 
focused on going into this 20% market, will look at the players, 
the tools and simply say: "Why D? Why not C++ 14/17/20".


This very much compact the issue that D has in attracting new 
users.

Re: Which language futures make D overcompicated?

[bachmeier via Digitalmars-d]

On Friday, 9 February 2018 at 22:36:19 UTC, Ralph Doncaster wrote:

While many more things were done right compared to C++, too 
many things were done wrong and there doesn't seem to be 
interest in breaking backward compatibility to excise them from 
D.


I agree. Some users might shout because they recompiled a piece 
of code for the first time in eight years and got an error. The 
users that don't shout are the ones that try out the language, 
see rough edges that should have been removed, and move on.


Enterprise users that want guaranteed language stability should 
pay to support a compiler for that version of the language. 
Archive a version of the compiler every two years and paying 
companies can be guaranteed to use that compiler forever. There's 
no reason to shut down the evolution of the language to satisfy 
one (currently very small) group of users.

typedef behavior with @disable this()

[Alex via Digitalmars-d-learn]

Do I overlook something?

/// --- code --- ///

import std.typecons;

void main(){}

static assert(!__traits( compiles, E()));
static assert(!__traits( compiles, MyE())); // line 6

struct E
{
size_t dummy;
@disable this();
this(size_t val) { dummy = val; }
}

alias MyE = Typedef!E;

/// --- code ends --- ///

While line 5 does not compile as expected, due to disabled 
default constructor, the Typedef'd type does. Why?

Re: A betterC base

[Timon Gehr via Digitalmars-d]

On 08.02.2018 16:55, JN wrote:

On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
Garbage collection has proved to be a smashing success in the 
industry, providing productivity and memory-safety to programmers of 
all skill levels.


Citation needed on how garbage collection has been a smashing success 
based on its merits rather than the merits of the languages that use 
garbage collection. Python was also a smashing success, but it doesn't 
use a garbage collector in it's default implementation (CPython). Unless 
you mean garbage collection as in "not manual memory management"? ...




Even if "garbage collection" is taken to mean "collecting garbage", 
reference counting is garbage collection. Referring to RC as not GC 
makes no sense at all and was probably only invented because some people 
want to think that RC is good but GC is bad, being too lazy to say 
"tracing GC".