Re: Reorganization and list of D libraries (300+)

[rikki cattermole via Digitalmars-d-announce]

On 07/11/2017 5:54 AM, Fra Mecca wrote:

On Tuesday, 7 November 2017 at 04:27:13 UTC, rikki cattermole wrote:

On 07/11/2017 12:35 AM, Fra Mecca wrote:

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke wrote:

[...]


Can we make a proposal for a change?


Sure ya can. Especially if it comes with a PR ;)


If I only had some front-end experience


Perfect time to learn.
Its a very useful skill to have, even if you don't use it every day.

Re: Reorganization and list of D libraries (300+)

[Fra Mecca via Digitalmars-d-announce]

On Tuesday, 7 November 2017 at 04:27:13 UTC, rikki cattermole 
wrote:

On 07/11/2017 12:35 AM, Fra Mecca wrote:
On Monday, 6 November 2017 at 16:12:14 UTC, Martin 
Tschierschke wrote:

[...]


Can we make a proposal for a change?


Sure ya can. Especially if it comes with a PR ;)


If I only had some front-end experience

Re: fputs, stdout

[rikki cattermole via Digitalmars-d-learn]

On 07/11/2017 4:34 AM, Tony wrote:
There is a fputs/stdout in core.stdc.stdio.  std.stdio "public imports" 
that:


"public import core.stdc.stdio;"

Wondering why:

import core.stdc.stdio : fputs;
import core.stdc.stdio : stdout;

void main()
{
    fputs( cast(const char *)"hello world\n",stdout);
}

compiles and runs, but if I change the imports to:

import std.stdio : fputs;
import std.stdio : stdout;

I get this compile error:

fputs_test.d(11): Error: function core.stdc.stdio.fputs (scope 
const(char*) s, shared(_IO_FILE)* stream) is not callable using argument 
types (const(char*), File)


core.stdc.stdio : stdout 
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d#L710
std.stdio : stdout 
https://github.com/dlang/phobos/blob/master/std/stdio.d#L4662


Answer: not the same thing.

Re: fputs, stdout

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, November 07, 2017 04:34:30 Tony via Digitalmars-d-learn wrote:
> There is a fputs/stdout in core.stdc.stdio.  std.stdio "public
> imports" that:
>
> "public import core.stdc.stdio;"
>
> Wondering why:
>
> import core.stdc.stdio : fputs;
> import core.stdc.stdio : stdout;
>
> void main()
> {
> fputs( cast(const char *)"hello world\n",stdout);
> }
>
> compiles and runs, but if I change the imports to:
>
> import std.stdio : fputs;
> import std.stdio : stdout;
>
> I get this compile error:
>
> fputs_test.d(11): Error: function core.stdc.stdio.fputs (scope
> const(char*) s, shared(_IO_FILE)* stream) is not callable using
> argument types (const(char*), File)

stdout in core.stdc.stdio and stdout in std.stdio are two different things.
In core.stdc.stdio it's a FILE*, and in std.stdio it's std.stdio.File.
Basically, core.stdc.stdio gives you the C version, and std.stdio gives you
the D version. However, there is no fputs in std.stdio. Rather, std.stdio
publicly imports core.stdc.stdio. So, it's the same fputs in
core.stdc.stdio, and it expects a FILE*, whereas since you import stdout
from std.stdio, you got the File, not the FILE*. So, they're not compatible.

- Jonathan M Davis

fputs, stdout

[Tony via Digitalmars-d-learn]

There is a fputs/stdout in core.stdc.stdio.  std.stdio "public 
imports" that:


"public import core.stdc.stdio;"

Wondering why:

import core.stdc.stdio : fputs;
import core.stdc.stdio : stdout;

void main()
{
   fputs( cast(const char *)"hello world\n",stdout);
}

compiles and runs, but if I change the imports to:

import std.stdio : fputs;
import std.stdio : stdout;

I get this compile error:

fputs_test.d(11): Error: function core.stdc.stdio.fputs (scope 
const(char*) s, shared(_IO_FILE)* stream) is not callable using 
argument types (const(char*), File)

Re: Reorganization and list of D libraries (300+)

[rikki cattermole via Digitalmars-d-announce]

On 06/11/2017 4:59 PM, jmh530 wrote:

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke wrote:


Even being the wrong Martin :-) I think the DUB registry really needs 
more and better filters, so that the gems inside can be found easily. 
(like: Number of Github stars, number of downloads, number of 
developers and in the future: money donated to this project ...).


There has been several attempts but I would like to encourage the D 
Foundation to put more focus on this. Better ecosystem around third 
party software means less work for improvement of standard lib.


Regards mt.


Agreed. (IMO more important than Elvis operator)


+[something]

If the DIP is too complex or big, it will be getting a no from me.
I just don't see any of those extra syntaxes being discussed as useful.

Re: Reorganization and list of D libraries (300+)

[rikki cattermole via Digitalmars-d-announce]

On 07/11/2017 12:35 AM, Fra Mecca wrote:

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke wrote:

On Saturday, 4 November 2017 at 00:16:35 UTC, Ali Çehreli wrote:

[...]


Even being the wrong Martin :-) I think the DUB registry really needs 
more and better filters, so that the gems inside can be found easily. 
(like: Number of Github stars, number of downloads, number of 
developers and in the future: money donated to this project ...).


There has been several attempts but I would like to encourage the D 
Foundation to put more focus on this. Better ecosystem around third 
party software means less work for improvement of standard lib.


Regards mt.


Can we make a proposal for a change?


Sure ya can. Especially if it comes with a PR ;)

ddox empty public methods/interfaces etc

[Andrey via Digitalmars-d-learn]

Hello is there way to automatically generate documentation for 
public methods, interfaces, fields etc.? e.g. now I should write 
somethink like this to generate documentation for enum Bacgkround:

///
enum Background {
transparent,  ///
light,  ///
dark,  ///
action,  /// Background for action panel, e.g. with buttons 
OK, Cancel etc.

}


I would like to write insted this:

enum Background {
transparent,
light,
dark,
action,  /// Background for action panel, e.g. with buttons 
OK, Cancel etc.

}


and avoid all redundant comments.

Re: [OT] Windows dying

[Jerry via Digitalmars-d]

On Saturday, 4 November 2017 at 02:33:35 UTC, Computermatronic 
wrote:
I, like many other windows users, want to be able to compile 
64bit binaries in windows, without having to download and 
install the bloated and time consuming to download and install 
Visual Studio.


I do most of my programming in Sublime Text, and frequently 
re-install windows. This may not be the case for many windows 
users of D, but clearly many windows users of D would like to 
be able to compile x64 out of the box.


So your fine with reinstalling Windows, going through the entire 
processing to setup and configure. Download all the new updates 
and install them. Then setup your environment, downloading 
potentially dozens of applications (git, debuggers, text editors, 
compilers, etc..) and configuring settings? But downloading 
Visual Studio is "time consuming".. I don't even. If all you can 
complain about Visual Studio is its download size then I'd say 
it's doing pretty good as a development tool.

Re: Any book recommendation for writing a compiler?

[Basile B. via Digitalmars-d-learn]

On Saturday, 4 November 2017 at 20:28:17 UTC, Ola Fosheim Grøstad 
wrote:

On Saturday, 4 November 2017 at 15:51:30 UTC, Basile B. wrote:
People who say that after reading the dragon book, you will 
program your own programming language are lying.


Well, you most certainly can write your own programming 
language after reading about 30% of the dragon book, but I 
think you can find easier books to get started these days.


I've just read the dragon book. let's write a compiler

https://imgur.com/1pFeat8

;-)

Re: What is the FreeBSD situation?

[Walter Bright via Digitalmars-d]

On 11/6/2017 4:30 PM, codephantom wrote:
It lead (I hope) to a greater understanding of the 
importance of FreeBSD and the need for D to pro-actively support it (remember 
FreeBSD really is the only mature open source alternative to gpl Linux - but it 
gets treated as a second class citizen by far too many


The FreeBSD port came from me having a soft spot for it :-) and also because Jan 
Knepper, our server provider, runs our web sites on a FreeBSD server.

Re: Reorganization and list of D libraries (300+)

[Fra Mecca via Digitalmars-d-announce]

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:

On Saturday, 4 November 2017 at 00:16:35 UTC, Ali Çehreli wrote:

[...]


Even being the wrong Martin :-) I think the DUB registry really 
needs more and better filters, so that the gems inside can be 
found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


There has been several attempts but I would like to encourage 
the D Foundation to put more focus on this. Better ecosystem 
around third party software means less work for improvement of 
standard lib.


Regards mt.


Can we make a proposal for a change?

Re: What is the FreeBSD situation?

[codephantom via Digitalmars-d]

On Monday, 6 November 2017 at 22:25:48 UTC, Andrei Alexandrescu 
wrote:
I've been asked why I have reduced my presence in this forum - 
and politely told it's being missed :o) - and the simple answer 
is I've noticed the forum discussions produce few results 
outside the forum. I'm still looking for the perfect formula 
that combines good forum engagement with palpable work.



Thanks,

Andrei


Well.. all I can say..is be careful.

If you make this forum like the FreeBSD forums, then people will 
stop engaging, and there goes your community(i.e go off topic 
in those forums and see what happens to you).


Disussions lead to discusions..lead to discussions...that's 
normal human behaviour.


Unexpected (OT) results can be useful for the D community too...

Perhaps some way to mark our thread as OT would be good. Then one 
could filter out OT discussion. But any attempt to stop OT 
discussion will come back and bite the community I believe. 
Humans' like discussing things too.


This thread did lead to some unintended outcomes, like me finding 
that gdc will compile code that dmd and ldc will not - 
apparentaly a bug in gdc, but a bug that I actually like. It lead 
(I hope) to a greater understanding of the importance of FreeBSD 
and the need for D to pro-actively support it (remember FreeBSD 
really is the only mature open source alternative to gpl Linux - 
but it gets treated as a second class citizen by far too many 
(e.g. the latested LDC release anouncement provides binaries for 
all platforms except FreeBSD??).


And most importantly, OT discussion in this thread may lead to a 
DMD for DOS! Now tell me that wasn't worth some OT discussion ;-)

Re: What is the FreeBSD situation?

[Walter Bright via Digitalmars-d]

On 11/6/2017 7:44 AM, Patrick Schluter wrote:
The 64 bit versions (not the Home editions) do support 16 bit but only by using 
full fledged virtual machine "Virtual PC", but it's like running on a separate 
machine.


When my XP machine finally dies I'm tempted to write that emulator :-) It would 
be very simple.

Re: Reorganization and list of D libraries (300+)

[Soulsbane via Digitalmars-d-announce]

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:

On Saturday, 4 November 2017 at 00:16:35 UTC, Ali Çehreli wrote:

On 11/03/2017 05:12 PM, Fra Mecca wrote:


https://github.com/FraMecca/D_Libraries_Registry


This effort should be combined with the current work being 
done to http://code.dlang.org/


I hope Martin, Seb, and others that are involved will see this 
thread. (Yes, I'm pinging them. :) )


Ali


Even being the wrong Martin :-) I think the DUB registry really 
needs more and better filters, so that the gems inside can be 
found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


There has been several attempts but I would like to encourage 
the D Foundation to put more focus on this. Better ecosystem 
around third party software means less work for improvement of 
standard lib.


Regards mt.


So true. I've written code before only to learn later that there 
was already a library for what I was doing that I just happened 
to stumble upon. Which would have saved me a lot of time.

Re: Improve "Improve Contract Syntax" DIP 1009

[Andrei Alexandrescu via Digitalmars-d]

On 11/1/17 11:11 PM, Meta wrote:

On Wednesday, 1 November 2017 at 22:04:10 UTC, Andrei Alexandrescu wrote:
We're having difficulty reviewing 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md. The value 
is there, but the informal and sometimes flowery prose affects the 
document negatively. There are some unsupported claims and detailed 
description is sketchy. We need a careful pass that replaces the 
unclear or imprecise statements with clear, straightforward scientific 
claims.


Can anyone help with this? For example, the first paragraph:

"D has already made a significant commitment to the theory of Contract 
Programming, by means of its existing in, out, and invariant 
constructs. But limitations remain to their usability, both in their 
syntax and in their implementation. This DIP addresses only the syntax 
aspect of those limitations, proposing a syntax which makes in, out, 
and invariant contracts much easier to read and write."


could be:

"The D language supports Contract Programming by means of its in, out, 
and invariant constructs. Their current syntactic form is 
unnecessarily verbose. This DIP proposes improvements to the contract 
syntax that makes them easier to read and write."


The change:

* eliminates the entire "implementation sucks" allegation which seems 
taken straight from a forum flamewar;


* replaces adjective-laden language with simple and precise statements;

* provides a brief factual overview of what follows.

Who wants to help?


Andrei


This actually makes the DIP slightly longer but hopefully makes it more 
clear.


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

I'm heading off to bed so I won't be able to respond right away to 
suggested changes.


Thanks! We're still looking for sizeable improvements. Any volunteers, 
please holler. -- Andrei

Re: What is the FreeBSD situation?

[Andrei Alexandrescu via Digitalmars-d]

On 11/2/17 12:25 AM, Andrei Alexandrescu wrote:
 From the recent PR-related discussion I gather that FreeBSD 12 has made 
some breaking changes to file primitives such as stat.


Do binaries built for pre-v12 crash on v12? If that's the case we should 
have two distinct build platforms, FreeBSD "legacy" and FreeBSD 12. They 
would be selected statically.


IF older binaries don't crash, what mechanism is FreeBSD 12 using to 
identify old API calls?


Thanks to all who answered. From what I gathered from the two on-topic 
responses, it seems binary compatibility is not provided across major 
versions. Like Walter, I'd be in favor of supporting the latest only.


Going slightly off-topic (ironically as will become obvious in a 
second), a sign of maturity in our community would be to use forum 
discussions as a catalyst and driver for work on new and existing 
projects. This thread seems to suggest we could improve on that, seeing 
that the majority of answers are off-topic and there is very little 
factual information or work items once this thread lives its course.


I've been asked why I have reduced my presence in this forum - and 
politely told it's being missed :o) - and the simple answer is I've 
noticed the forum discussions produce few results outside the forum. I'm 
still looking for the perfect formula that combines good forum 
engagement with palpable work.



Thanks,

Andrei

Re: Project Elvis

[Michael via Digitalmars-d]

I can't quite see why this proposal is such a big deal to people 
- as has been restated, it's just a quick change in the parser 
for a slight contraction in the code, and nothing 
language-breaking, it's not a big change to the language at all.


On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:
I am all for the Elvis operator, however I have two 
reservations about it. The first is that I don't see much use 
for it without a null-conditional. The second is that the 
current proposed syntax ?: is MUCH to easily confused with ?.


This is not easy to read: obj1?.obj2?.prop3?:constant.

When designing syntax sugar, ergonomics are very important, 
otherwise people won't use it. Microsoft spent a LOT of time 
and treasure to learn these lessons for us. I see no reason to 
ignore them just because "we don't like Microsoft"


My proposal would be to copy what MSFT did, expect that I would 
I would introduce both operators at the same time.


Syntax as follows: obj1?.obj2?.prop3 ?? constant

In practice I don't see much use of the idiom outside of 
null's. The ONLY other thing that would work there is a boolean 
field and you might as well just return the boolean itself 
because the return values have to match types.


I feel this is kind of embellished somewhat. When you write


This is not easy to read: obj1?.obj2?.prop3?:constant.


you're not separating it out as you do when you write your 
preferred version:



Syntax as follows: obj1?.obj2?.prop3 ?? constant


How is


obj1?.obj2?.prop3 ?: constant


not as easy to read as



obj1?.obj2?.prop3 ?? constant


to me they are the same in terms of readability, only with ?? you 
have greater chances of mistyping and adding a second ? in there 
somewhere, whereas the ?: is just a contraction of the current 
syntax, I really don't think it's that difficult, so I'm not sure 
what people's hang-ups are, but I don't think the argument that 
?? is easier to read than ?: holds any weight here, because one 
*is* a change to the language, and the other is a change to the 
parser and a contraction of a standard convention.

Re: Project Elvis

[Meta via Digitalmars-d]

On Monday, 6 November 2017 at 19:55:13 UTC, Jacob Carlborg wrote:

On 2017-11-06 20:40, Dmitry Olshansky wrote:

I’d argue this NOT what we want. Nullability is best captured 
in the typesystem even if in the form of Nullable!T.


Yeah, it would be better if the elvis operator good integrate 
with a nullable/option type as well in addition to null.


What's the point when we can already do it easily in a library, 
and arguably with better ergonomics? 
(http://forum.dlang.org/post/fshlmahxfaeqtwjbj...@forum.dlang.org)


auto tree = new Node(1,
   new Node(2),
   new Node(3,
   null,
   new Node(4)
   )
   );

import std.stdio;
writeln(safeDeref(tree).right.right.val.orElse(-1));
writeln(safeDeref(tree).left.right.left.right.orElse(null));
writeln(safeDeref(tree).left.right.left.right.val.orElse(-1));

vs.

writeln(tree?. right?.right?.val ?: -1);
writeln(tree?.left?.right?.left?.right);
writeln(tree?.left?.right?.left?.right?.val ?: -1);

The functionality is probably a good idea, but a library solution 
is doable today without any acrobatics.

Re: Project Elvis

[Jacob Carlborg via Digitalmars-d]

On 2017-11-06 20:40, Dmitry Olshansky wrote:

I’d argue this NOT what we want. Nullability is best captured in the 
typesystem even if in the form of Nullable!T.


Yeah, it would be better if the elvis operator good integrate with a 
nullable/option type as well in addition to null.


--
/Jacob Carlborg

Re: Reorganization and list of D libraries (300+)

[Dmitry Olshansky via Digitalmars-d-announce]

On Monday, 6 November 2017 at 16:59:52 UTC, jmh530 wrote:
On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:


Even being the wrong Martin :-) I think the DUB registry 
really needs more and better filters, so that the gems inside 
can be found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


There has been several attempts but I would like to encourage 
the D Foundation to put more focus on this. Better ecosystem 
around third party software means less work for improvement of 
standard lib.


Regards mt.


Agreed. (IMO more important than Elvis operator)


+111

Re: Project Elvis

[Dmitry Olshansky via Digitalmars-d]

On Monday, 6 November 2017 at 19:13:59 UTC, Adam Wilson wrote:

On 10/28/17 04:38, Andrei Alexandrescu wrote:
Walter and I decided to kick-off project Elvis for adding the 
homonym

operator to D.

Razvan Nitu has already done a good part of the work:

https://github.com/dlang/dmd/pull/7242
https://github.com/dlang/dlang.org/pull/1917
https://github.com/dlang/dlang.org/pull/1918


Some years later the C# team introduces the Null-Conditional 
operator: ?. which allows you to write: obj1?.obj2?.prop3 ?? 
constant.


NOW people start using Null Coalescing all over the place.



So C# embraced the Null. Everything is nullable and you are 
expected to ?. proof it if you don’t know in advance.


In contrast other languages (e.g. Scala) decided to discourage 
the use of null in favor of algebraic type Option!T and even 
remove the null all together.


I am all for the Elvis operator, however I have two 
reservations about it.


To me the biggest reservation is “embracing the null” that this 
entails.


In other words since we dedicate a feature to support nulls that 
indicates null return is an endorsed aproach to e.g. model APIs 
and libraries that deal with optional values.


I’d argue this NOT what we want. Nullability is best captured in 
the typesystem even if in the form of Nullable!T.

Re: Project Elvis

[Adam Wilson via Digitalmars-d]

On 10/28/17 04:38, Andrei Alexandrescu wrote:

Walter and I decided to kick-off project Elvis for adding the homonym
operator to D.

Razvan Nitu has already done a good part of the work:

https://github.com/dlang/dmd/pull/7242
https://github.com/dlang/dlang.org/pull/1917
https://github.com/dlang/dlang.org/pull/1918

What's needed is a precise DIP that motivates the feature properly and
provides a good proposal for it. I'm no fan of bureaucracy but we really
need to be pedantic about introducing language features. Walter argued
thusly in a PR, and I agree:

"I'm concerned that the elvis operator is not well understood, and we
shouldn't be designing it in the comments section here. A DIP needs to
be written. Things like operator precedence, side effects, type
resolution, comparison with the operator in other languages, grammar
changes, lvalues, how it would appear in the generated .di file if it
isn't its own operator, etc., should be addressed."

A lowering looks like the straightforward approach, of the kind:

expr1 ?: expr2

==>

(x => x ? x : expr2)(expr1)

Who wants to join Razvan in Project Elvis?


Thanks,

Andrei



C# has extensive experience with this operator and I think it would be 
wise to study the history of what they did and why the did it. NOTE: I 
understand that other languages have it, and there are variations on the 
theme, but C# has many similarities to D and extensive "in practice" idioms.


C# got the Elvis operator before it got the Null Conditional operator. 
In C# it only covers the case: a == null. The reason is that in practice 
most devs only use it like so: a != null ? a : b.


The funny thing is that it was almost never used.

Some years later the C# team introduces the Null-Conditional operator: 
?. which allows you to write: obj1?.obj2?.prop3 ?? constant.


NOW people start using Null Coalescing all over the place.

I am all for the Elvis operator, however I have two reservations about 
it. The first is that I don't see much use for it without a 
null-conditional. The second is that the current proposed syntax ?: is 
MUCH to easily confused with ?.


This is not easy to read: obj1?.obj2?.prop3?:constant.

When designing syntax sugar, ergonomics are very important, otherwise 
people won't use it. Microsoft spent a LOT of time and treasure to learn 
these lessons for us. I see no reason to ignore them just because "we 
don't like Microsoft"


My proposal would be to copy what MSFT did, expect that I would I would 
introduce both operators at the same time.


Syntax as follows: obj1?.obj2?.prop3 ?? constant

In practice I don't see much use of the idiom outside of null's. The 
ONLY other thing that would work there is a boolean field and you might 
as well just return the boolean itself because the return values have to 
match types.


For example:
return obj1.bool ?? obj2 //Error: incorrect return type
return obj1 ?? obj2 // Pass: if same type

I cannot actually imagine a scenario outside of objects (including 
strings) where you could actually use it since the left-hand side MUST 
evaluate to a boolean.


Also, I am going to start repeating this mantra: Just because something 
CAN be done in the library, does not mean it SHOULD be done in the library.


Ergonomics matters. Yes, I understand that D is a powerful language, but 
Syntax Sugar has it's place in taking common idioms and standardizing 
them in the language itself (English is loaded with stuff like that) so 
that everyone can "speak the same language".


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: Bug or "hidden" feature?

[Timon Gehr via Digitalmars-d]

On 06.11.2017 10:50, bauss wrote:




Feature as return type is not necessary and considered auto when some 
qualifiers are added


const foo() {}

@property foo() {}

etc


Yeah I was aware of it for build-in attributes, but didn't know it 
applied to user-defined attributes. 
This is a common misconception. Auto means 'automatic storage' (a C 
leftover), not 'automatic type deduction'. 'auto' (or some other storage 
class/attribute) is only required to make it clear that what follows is 
a declaration. To enable type deduction, just don't specify the type.

[Issue 17969] [REG 2.077.0] dmd 2.077.0 crashes when computing mangling symbol for simple program

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com
Summary|dmd 2.077.0 crashes when|[REG 2.077.0] dmd 2.077.0
   |computing mangling symbol   |crashes when computing
   |for simple program  |mangling symbol for simple
   ||program
   Severity|critical|regression

--- Comment #1 from ag0ae...@gmail.com ---
Reduced:


alias fun = a => MapResult2!(b => b).sum;

int[] e;
static assert(!is(typeof(fun(e)) == void));
void foo() { fun(e); }

struct MapResult2(alias fun)
{
int[] _input;
}


--

Re: Keyword scope as qualifier on destructors

[Jonathan M Davis via Digitalmars-d-learn]

On Monday, November 06, 2017 15:51:15 Nordlöw via Digitalmars-d-learn wrote:
> What effect does `scope`-qualification have for destructors such
> as
>
>  ~this() @trusted scope;
>
> used here
>
> https://github.com/dlang/dmd/pull/7284/files#diff-da63c10313833b6da044c7e5
> e3a85c03R67
>
> ?

Without -dip1000? Nothing. With -dip1000, I'd guess that it has to do with
pointers or references marked with scope, but I don't know. DIP 1000 might
say. If not, then you'd probably have to ask Walter. scope ends up in all
kinds of new, weird places with -dip1000. He covered some of it in his dconf
talk this year, but I don't know how much things have changed since then.

- Jonathan M Davis

Re: Reorganization and list of D libraries (300+)

[jmh530 via Digitalmars-d-announce]

On Monday, 6 November 2017 at 16:12:14 UTC, Martin Tschierschke 
wrote:


Even being the wrong Martin :-) I think the DUB registry really 
needs more and better filters, so that the gems inside can be 
found easily. (like: Number of Github stars, number of 
downloads, number of developers and in the future: money 
donated to this project ...).


There has been several attempts but I would like to encourage 
the D Foundation to put more focus on this. Better ecosystem 
around third party software means less work for improvement of 
standard lib.


Regards mt.


Agreed. (IMO more important than Elvis operator)

Re: Strange AV in asm mode (code only for amd64)

[user1234 via Digitalmars-d-learn]

On Sunday, 5 November 2017 at 14:25:24 UTC, user1234 wrote:

On Sunday, 5 November 2017 at 13:43:15 UTC, user1234 wrote:

[...]


Hmmm it was just the amount of nops.

---
import std.stdio;

alias Proc = size_t function();

size_t allInnOne()
{
asm pure nothrow
{
naked;
mov RAX, 1;
ret;
nop;nop;
mov RAX, 2;
ret;
}
}

void main()
{
Proc proc1 = 
Proc proc2 = cast(Proc) (cast(void*) + 8);
writeln(proc1(), " ",proc2());
}
---


That's a nice trick against static analysis. I imagine well an 
attacker trying to fight against the first part, even if never 
executed, assuming he found that this function got executed and 
then he assumes that the code get executed from the start.

[Issue 4946] Not good error message with wrongly positioned 'const'

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

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

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

https://github.com/dlang/dmd/commit/f9879d74ea09034e68829551c3b3902c28e08bec
Fix Issue 4946 - Not good error message with wrongly positioned 'const'

https://github.com/dlang/dmd/commit/05fcb67900f5233f77584b6dd21da31d04702e13
Merge pull request #7280 from RazvanN7/Issue_4946

Fix Issue 4946 - Not good error message with wrongly positioned 'const'
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: Reorganization and list of D libraries (300+)

[Martin Tschierschke via Digitalmars-d-announce]

On Saturday, 4 November 2017 at 00:16:35 UTC, Ali Çehreli wrote:

On 11/03/2017 05:12 PM, Fra Mecca wrote:


https://github.com/FraMecca/D_Libraries_Registry


This effort should be combined with the current work being done 
to http://code.dlang.org/


I hope Martin, Seb, and others that are involved will see this 
thread. (Yes, I'm pinging them. :) )


Ali


Even being the wrong Martin :-) I think the DUB registry really 
needs more and better filters, so that the gems inside can be 
found easily. (like: Number of Github stars, number of downloads, 
number of developers and in the future: money donated to this 
project ...).


There has been several attempts but I would like to encourage the 
D Foundation to put more focus on this. Better ecosystem around 
third party software means less work for improvement of standard 
lib.


Regards mt.

[Issue 4946] Not good error message with wrongly positioned 'const'

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

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

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

   What|Removed |Added

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

--

Keyword scope as qualifier on destructors

[Nordlöw via Digitalmars-d-learn]

What effect does `scope`-qualification have for destructors such 
as


~this() @trusted scope;

used here

https://github.com/dlang/dmd/pull/7284/files#diff-da63c10313833b6da044c7e5e3a85c03R67

?

[Issue 17194] [scope] Fwd reference error with nested struct

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

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

--- Comment #5 from radu.raca...@gmail.com ---
Just to point that "scope" is to blame here, removing "scope" from the inner
stuct ctor like:

+++
struct V
{
W w;

struct W
{
this(/*scope*/ ref V v)
{
this.v = 
}
V* v;
}
}

void main()
{
V v;
}
+++

compiles without errors.

--

[Issue 9682] Propagate range sortedness property throughout Phobos algorithms

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

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

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from RazvanN  ---
Closing per discussion:

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

--

Re: What is the FreeBSD situation?

[Patrick Schluter via Digitalmars-d]

On Sunday, 5 November 2017 at 20:28:38 UTC, Walter Bright wrote:

On 11/5/2017 3:13 AM, Patrick Schluter wrote:
On Sunday, 5 November 2017 at 09:17:37 UTC, Walter Bright 
wrote:
I run dmd regularly on an XP box, but that just means dmd 
itself runs on XP. (I converted the front end of DMC++ to D, 
using DMD in -betterC mode, and XP is the last operating 
system that supports DOS programs. XP has the DOS DMC++ test 
suite on it.)


I don't think that's true. It's a 32bit/64bit division, not a 
Windows version thing. A 32 bits installation can run 16 bits 
and 32 bits programs, a 64 bits version can run natively 32 
bits and 64 bits programs. None can run all 3 modes natively.


Is that an issue with the CPU, or the operating system?


CPU officially V86 is not supported in 64 bit mode. But I read a 
long time ago in c't that it was technically possible to invoke 
V86 mode when running 32 bit code in loing mode, but that it was 
quite tricky and required quite some planning to do in all cases 
(page table tricks [1]). Microsoft decided to not do these kind 
of tricks and allows only V86 mode in 32 bits installations.
Furthermore, neither AMD not Intel really document that it is 
possible and it could be that future version of the CPU will not 
allow for it (the issue with VME mode in Ryzen seem to show that 
the manufacturers test these exotic legacy modes less and less 
[2][3]).




I know with certainty that Windows 8.1 32 bits installation 
could still run DOS and Windows 16 bits apps. I haven't seen 
evidence to the contrary for Windows 10.
Windows XP was the last version that was installed massively 
in 32 bits mode.
 From Vista on, the proportion of 32 bits installations (and 
thus losing 16 bits support) dwindeled.


Windows 7  64 bit will not run 16 bit programs. Try it and you 
get a dialog box "Unsupported 16-Bit Application". I haven't 
tried Win 7 32, but some googling around shows you are correct.


The 64 bit versions (not the Home editions) do support 16 bit but 
only by using full fledged virtual machine "Virtual PC", but it's 
like running on a separate machine.


[1]: 
https://groups.google.com/forum/#!msg/comp.lang.asm.x86/wfK2LjhCqjw/XoeBgYWyv5EJ

[2]: http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/
[3]: http://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/

[Issue 17971] New: Cannot compare 2 functions

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

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

  Issue ID: 17971
   Summary: Cannot compare 2 functions
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: razvan.nitu1...@gmail.com

Momentarily you cannot compare 2 functions in phobos. For more information see
[1].

[1] https://github.com/dlang/phobos/pull/5712

--

[Issue 17970] New: shared struct destructor doesn't compile anymore

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

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

  Issue ID: 17970
   Summary: shared struct destructor doesn't compile anymore
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: radu.raca...@gmail.com

The following:

+foo.d++

shared struct Shared
{
static shared(Shared) make()
{
  return shared(Shared)();
}

~this()
{
}
}

void main()
{
auto s = Shared.make();
}

+++

Compiles with 2.072 and 2.074, fails with upward versions including 2.077 with
this error:

Error: shared method foo.Shared.~this is not callable using a non-shared object

--

Re: Improve "Improve Contract Syntax" DIP 1009

[Timon Gehr via Digitalmars-d]

On 06.11.2017 03:32, Jonathan M Davis wrote:


I'm sure that there are various things that could be done to improve
contracts (and DIP 1009 is one such attempt), but I've mostly given up on
it. I don't think that they provide enough value in the first place. Aside
from issues involving contracts and inheritance, in contracts can just be
put in the function body,


The point of the in contract is to establish that it is the caller, and 
not the library author, who is responsible for ensuring it is satisfied.
It is slightly more obvious why this is crucial if your language has 
tooling for verifying assertions.



making them kind of pointless, and for the most
part, unit tests test anything that I would consider testing in an out
contract


Then you are doing it wrong.


- and generally do it better.


Unit tests alone do not test your code better than both unit tests and 
contracts.

[Issue 17968] [REG 2.073] object initializer omitted when it should be included.

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

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

--- Comment #3 from Steven Schveighoffer  ---
Further reduced mod1:

module mod1;

class IOObject(IO) {
}

struct BufferedInputSource(Source)
{
Source dev;
}

BufferedInputSource!Source bufd(Source)(Source s)
{
return BufferedInputSource!Source();
}

auto openDev(int )
{
return new IOObject!int;
}

--

[Issue 17507] Associative Array range operations should be marked @safe

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

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

--- Comment #1 from Steven Schveighoffer  ---
This is effectively fixed by https://github.com/dlang/druntime/pull/1944

--

[Issue 17108] Associative array byKeyValue is unsafe

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

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

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

https://github.com/dlang/druntime/commit/51003a398b77eca1b01138412f2e363c38172878
fix issue 17108 Associative array byKeyValue is unsafe

https://github.com/dlang/druntime/commit/3bf2559ce08d449d8d486a4df3f74343f5b70b33
Merge pull request #1944 from somzzz/make_foreach_byKeyValue_safe

fix issue 17108 Associative array byKeyValue is unsafe

--

[Issue 17108] Associative array byKeyValue is unsafe

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

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

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

   What|Removed |Added

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

--

[Issue 7184] parse error on *(x)++

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

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

--- Comment #10 from RazvanN  ---
(In reply to timon.gehr from comment #9)
> (In reply to timon.gehr from comment #8)
> > (In reply to RazvanN from comment #1)
> > > Issuing an error is the correct behavior. As you can see in the grammar 
> > > [1], 
> > > *(x)++ is parsed the following way: *UnaryExpression. If a parenthesis is
> > > encountered, then the parser expects a type :
> > > (type).identifier/templateInstance.
> > 
> > That is the bug. The grammar allows the derivation
> > 
> > UnaryExpression
> >   \
> > PowExpression
> > \
> >   PostfixExpression
> >   \
> > PostfixExpression ++
> > \
> >  ( PrimaryExpression )
> >   \
> >   ...
> > \
> >  Identifier
> > 
> 
> Should have been:
> 
> UnaryExpression
>   \
> PowExpression
> \
>   PostfixExpression
>   \
> PostfixExpression ++
> \
>   PrimaryExpression
>   \
>( Expression )
> \
> ...
>   \
>Identifier

That is correct. I looked at the code which tests that the content of the
parentheses is a type and at the UnaryExpression expression grammar so I
presumed that you cannot have the given construct. I understand now that indeed
this is not acceptable behavior. Thanks

--

Re: Project Elvis

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
wrote:

All it does is take the expression

x ? x : y

and make it

x ?: y


Yes, that is an issue because it means that typos no longer are 
caught. E.g. if you accidentally comment out or delete the second 
expression.


Which is why I think ?? or some other choice would offer better 
usability.


The difference is that you think that the feature is worth the 
cost, not that the folks who don't want to use the feature 
don't have to pay the cost.


Indeed.

[Issue 17186] Type inference for parameters with default argument

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

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #4 from Nick Treleaven  ---
There was a pull for this before:

https://github.com/dlang/dmd/pull/2270
https://issues.dlang.org/show_bug.cgi?id=10491

Now this is preapproved, it could be updated.

--

Re: Project Elvis

[Biotronic via Digitalmars-d]

On Monday, 6 November 2017 at 10:12:11 UTC, Jonathan M Davis 
wrote:

x ? x : y

and make it

x ?: y

It saves 2 characters plus the length of the variable name. 
That's it.


I find I often use this in C# with a more complex expression on 
the left-hand side, like a function call. A quick search shows 
more than 2/3 of my uses are function calls or otherwise 
significantly more complex than a variable. Also, it works great 
in conjunction with the null conditional:


foo.Select(a => bar(a, qux)).FirstOrDefault?.Name ?? "not found";

It seems to be targeted primarily at code that does a lot with 
classes and is written in such a way that it's not clear 
whether a class reference should be null or not, whereas most D 
code doesn't do much with classes.


In my C# code, it's used with strings and Nullable more often 
than with classes.


Given my own experience with the ?? operator, I'd argue it's 
probably not worth it without also including null conditional 
(?.). A quick search in a few projects indicate roughly half the 
uses of ?? also use ?..


--
  Biotronic

Re: Project Elvis

[Andrei Alexandrescu via Digitalmars-d]

On 11/05/2017 07:20 PM, Neia Neutuladh wrote:

On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote:
Walter and I decided to kick-off project Elvis for adding the homonym 
operator to D.


It's easy to write in function form:

   auto orElse(T)(T a, lazy T b)
   {
     return a ? a : b;
   }

   writeln(args[1].length.orElse(fibonacci(50)));

This version can also be specialized for things like Nullable, where you 
can't necessarily cast it safely to a boolean but have a check for 
validity.


Is it that valuable to have an operator for it instead?


As an aside, I believe feepingcreature had a custom infix operator for 
this sort of thing defined, so you could write:


   (a /or/ b /or/ c).doStuff();

The implementation (along with /and/) is left as an exercise to the reader.


If a DIP emerges, it would need to present such alternatives and argue 
how it adds value over them. -- Andrei

[Issue 17969] New: dmd 2.077.0 crashes when computing mangling symbol for simple program

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

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

  Issue ID: 17969
   Summary: dmd 2.077.0 crashes when computing mangling symbol for
simple program
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: atila.ne...@gmail.com

This code causes dmd 2.070.0 to crash:

void foo() {
struct Data {
double value;
}
oops([Data()]);
}


void oops(Data)(Data[] data) {
import std.algorithm: map;
auto values = [data].map!(a => a.map!(b => b.value).sum);
}

Earlier versions aren't affected. Notice that `sum` isn't imported. If it is,
the crash goes away. If `b.value` is replaced with `b.foo` (or any other name
that doesn't exist in the struct), it also crashes, so it seems to have to do
with the function failing to compile.

The stack trace points to
_ZN7Mangler14mangleFuncTypeEP12TypeFunctionS1_hP4Type.

--

switch - Re: Improve "Improve Contract Syntax" DIP 1009

[Nick Treleaven via Digitalmars-d]

On Thursday, 2 November 2017 at 20:37:11 UTC, user1234 wrote:

switch (i)
default: break;
}

you have 3 non-ambiguous and contiguous statements without a 
block: a switch, a default case (the "free-floating" one) and a 
break. Now why is this allowed is another story ;)


I've found a use for it - breakable blocks. (It's a bit neater 
than putting the label inside the block):


switch (1) default:
{
auto x = foo();
if (x == bar) break;
auto y = x.baz();
if (!y) break;
y.writeln;
}

This avoids indentation from nested if statements instead of 
breaks. Although this is not ideal syntax, it's better than 
abusing a loop construct for something that's not a loop. Using a 
goto makes the code read less naturally as the label is after the 
block.

[Issue 17964] [CTFE] If array is large enough it hits __simd at CTFE

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

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

  Component|dmd |druntime

--

[Issue 17964] [CTFE] If array is large enough it hits __simd at CTFE

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

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 CC||uplink.co...@googlemail.com

--- Comment #1 from uplink.co...@googlemail.com ---
What needs to be done here is a change in druntime/src/core/internal/arrayops.d
adding a __ctfe branch to load and store which works without simd intrinsics.

I will take this if it is not fixed by the end of the week

--

Re: Bug or "hidden" feature?

[Jonathan M Davis via Digitalmars-d]

On Monday, November 06, 2017 09:50:47 bauss via Digitalmars-d wrote:
> On Monday, 6 November 2017 at 09:48:39 UTC, Temtaime wrote:
> > On Monday, 6 November 2017 at 09:44:24 UTC, bauss wrote:
> >> If a function has an UDA you don't need to give the function a
> >> return type.
> >>
> >> Is that a bug or a hidden feature?
> >>
> >> Example:
> >>
> >> ```
> >> import std.stdio;
> >>
> >> struct A { }
> >>
> >> @A test()
> >> {
> >>
> >>writeln("Called test()");
> >>
> >> }
> >>
> >> @A test2()
> >> {
> >>
> >>return true;
> >>
> >> }
> >>
> >> void main()
> >> {
> >>
> >>test();
> >>writeln(test2());
> >>
> >> }
> >> ```
> >
> > Feature as return type is not necessary and considered auto
> > when some qualifiers are added
> >
> > const foo() {}
> >
> > @property foo() {}
> >
> > etc
>
> Yeah I was aware of it for build-in attributes, but didn't know
> it applied to user-defined attributes. Always thought you had to
> be explicit about "auto" there, but I guess not.

The same goes for variables. The type is always infered if it's not
explicit. It's just that auto is required when there isn't something else
there to indicate that it's a variable or function declaration. e.g.

enum foo = "bar";

or

static baz = 42;

or

immutable hello = "world";

- Jonathan M Davis

Re: Proposal: Support for objects in switch statements

[Atila Neves via Digitalmars-d]

On Wednesday, 1 November 2017 at 01:16:32 UTC, solidstate1991 
wrote:
After I started to alter my graphics engine to use the multiple 
kinds of bitmaps (now using multiple language features, like 
templates and aliases) on one layer, I noticed that type 
detection of bitmap objects would be easier and better 
readable, if instead of:


if(bitmapObject.classinfo == typeof(Bitmap4Bit)){
...
}else if(bitmapObject.classinfo == typeof(Bitmap8Bit)){...

I could easily use this:

switch(bitmapObject.classinfo){
case typeof(Bitmap4Bit):
...
case typeof(Bitmap8Bit):
}

On the other hand I cannot really think other uses for such 
language feature, maybe with structs.


Checking for types at runtime is a code smell in OOP. Sometimes 
necessary, especially if doing multiple dispatch, but never done 
gladly. There's already a way to dispatch on type: virtual 
functions.


Atila

Re: What are the unused but useful feature you know in D?

[Atila Neves via Digitalmars-d]

On Sunday, 5 November 2017 at 03:02:52 UTC, rikki cattermole 
wrote:

On 04/11/2017 6:13 PM, bauss wrote:
On Saturday, 4 November 2017 at 13:27:29 UTC, rikki cattermole 
wrote:

[...]


It reminds a lot of traits in Rust.

https://doc.rust-lang.org/1.8.0/book/traits.html


Rust traits are a variant of ML's signature. Only they decided 
to add a whole new concept which is 'impl' to it.


While it is a nice idea, it would be a pain to use in real life 
and defeat the purpose of a signature. Which is to act as more 
of a 'concept' abstraction to other items.


Because we have such powerful meta-programming features I see 
no reason to separate out the two. We can do it all in one 
which makes it nice and consistent between all the different 
implementations for a signature type. So far its starting to 
feel right at home against our structs and class support, I 
think.


I like Rust's traits more than our way of ad-hoc specification of 
compile-time interfaces with is(typeof({...})) or 
__traits(compiles, ...). Given how most idiomatic D code is 
written, to me that's the biggest deficiency of the language. 
Reasonable people may, of course, disagree.


Atila

Re: Project Elvis

[Jonathan M Davis via Digitalmars-d]

On Monday, November 06, 2017 09:26:24 Satoshi via Digitalmars-d wrote:
> Look, this operator does not break anything. If you don't want to
> use it, just don't, but why do you force everyone else to not to
> use it, just because it is not adding anything "more valuable"
> than just better syntax?

_Everything_ that is added to the language complicates it further. It's one
more thing that everyone learning the language has to learn and know and
potentially deal with in code. Obviously, some things are worth the extra
complication, or we'd all be programming in C, but there is always a cost to
adding something, and the feature needs to be worth that cost.

Granted, the elvis operator as proposed is not all that complicated, but
adding it does make the language that much more complex, and it really
doesn't do much. All it does is take the expression

x ? x : y

and make it

x ?: y

It saves 2 characters plus the length of the variable name. That's it. And
it's optimizing an idiom that isn't going to tend to show up much in
idiomatic D code. It seems to be targeted primarily at code that does a lot
with classes and is written in such a way that it's not clear whether a
class reference should be null or not, whereas most D code doesn't do much
with classes. Rather, it does a lot with ranges and structs on the stack.
Obviously, some code uses classes, and I expect that some code would benefit
from the elvis operator, but I dispute that it's a common enough idiom to
merit being added the language.

Personally, while I frequently use the ternary operator, I almost never end
up with the left and middle branches being the same, which is the only place
that the elvis operator would be useful. And I don't think that Phobos does
it much either. So, unless a lot of D code out there is using a drastically
different coding style that does a lot with null, the elvis operator will
not help much D code.

So, IMHO, the elvis operator adds very little value, and I'd just as soon
not see the language complicated further without adding real value in the
process. So, I'll argue against it, but ultimately, it's not my decision.
Rather, it's up to Walter and Andrei, and they'll decide what they decide.

But don't expect anyone not to be unhappy about a feature being added to the
language when they don't think that the feature adds value, because there is
always a cost to a new feature. The difference is that you think that the
feature is worth the cost, not that the folks who don't want to use the
feature don't have to pay the cost.

- Jonathan M Davis

[Issue 10756] "has no effect in expression" error message with correct type name

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

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

Mike  changed:

   What|Removed |Added

   Keywords||trivial
 CC||slavo5...@yahoo.com

--

Re: Bug or "hidden" feature?

[bauss via Digitalmars-d]

On Monday, 6 November 2017 at 09:48:39 UTC, Temtaime wrote:

On Monday, 6 November 2017 at 09:44:24 UTC, bauss wrote:
If a function has an UDA you don't need to give the function a 
return type.


Is that a bug or a hidden feature?

Example:

```
import std.stdio;

struct A { }

@A test()
{
writeln("Called test()");
}

@A test2()
{
return true;
}

void main()
{
test();
writeln(test2());
}
```


Feature as return type is not necessary and considered auto 
when some qualifiers are added


const foo() {}

@property foo() {}

etc


Yeah I was aware of it for build-in attributes, but didn't know 
it applied to user-defined attributes. Always thought you had to 
be explicit about "auto" there, but I guess not.

Re: Bug or "hidden" feature?

[Temtaime via Digitalmars-d]

On Monday, 6 November 2017 at 09:44:24 UTC, bauss wrote:
If a function has an UDA you don't need to give the function a 
return type.


Is that a bug or a hidden feature?

Example:

```
import std.stdio;

struct A { }

@A test()
{
writeln("Called test()");
}

@A test2()
{
return true;
}

void main()
{
test();
writeln(test2());
}
```


Feature as return type is not necessary and considered auto when 
some qualifiers are added


const foo() {}

@property foo() {}

etc

Bug or "hidden" feature?

[bauss via Digitalmars-d]

If a function has an UDA you don't need to give the function a 
return type.


Is that a bug or a hidden feature?

Example:

```
import std.stdio;

struct A { }

@A test()
{
writeln("Called test()");
}

@A test2()
{
return true;
}

void main()
{
test();
writeln(test2());
}
```

Re: Project Elvis

[Satoshi via Digitalmars-d]

On Monday, 6 November 2017 at 08:06:54 UTC, Jonathan M Davis 
wrote:
On Monday, November 06, 2017 07:10:43 bauss via Digitalmars-d 
wrote:
On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh 
wrote:

> On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei
>
> Alexandrescu wrote:
>> [...]
>
> It's easy to write in function form:
>   auto orElse(T)(T a, lazy T b)
>   {
>
> return a ? a : b;
>
>   }
>
>   writeln(args[1].length.orElse(fibonacci(50)));
>
> This version can also be specialized for things like 
> Nullable, where you can't necessarily cast it safely to a 
> boolean but have a check for validity.

>
> Is it that valuable to have an operator for it instead?
>
>
> As an aside, I believe feepingcreature had a custom infix
>
> operator for this sort of thing defined, so you could write:
>   (a /or/ b /or/ c).doStuff();
>
> The implementation (along with /and/) is left as an exercise 
> to

> the reader.

Sure you might be able to write it easily, but pretty much 
everyone writes a function like that in their projects and you 
don\t really know the implementation always and you have to 
remember the exact name or else you end up writing the 
function yourself in your project to make sure the 
implementation is exactly like that, which in fact turns out 
to be re-inventing the wheel.


By having an official syntax for it, you don't end up with 
code duplication like that and the implementation details of 
the behavior is clear.


Because in some implementation "orElse()" might only check if 
the value is null and not necessary if the value is true.


Ex. one might implement it like:

auto orElse(T)(T a, lazy T b)
{
  return a !is null ? a : b;
}

Such implementation detail is not clear from the call-side.

However with an official implementation you know exactly how 
it will behave and nothing is obscure like this.


That might be an argument for having an official 
implementation, but it's not really an argument for why it 
should be built into the language; it could just as easily be 
in Phobos if that's all that matters.


- Jonathan M Davis


You need additional import for this
verbose syntax
https://en.wikipedia.org/wiki/Syntactic_sugar
Why we have operators overloading when we could have Equals() and 
stuff like in java?
Why we have arr ~= arr2 when we could have Array.mergeArrays(arr, 
arr2) instead?


Look, this operator does not break anything. If you don't want to 
use it, just don't, but why do you force everyone else to not to 
use it, just because it is not adding anything "more valuable" 
than just better syntax?

Re: Creating a C# like Asynchronous Socket

[DrCataclysm via Digitalmars-d-learn]

On Monday, 6 November 2017 at 08:03:23 UTC, DrCataclysm wrote:

On Sunday, 5 November 2017 at 14:47:37 UTC, DrCataclysm wrote:
I am trying to build something like the asynchronous Sockets 
from C# .NET but I'm stuck at the accepting phase.




The client created by _socket.accept() cannot receive any data.

client.receive() immediately returns 0 like a non-blocking 
socket. I think it has something to do with the original 
socket being owned by a different thread.


I am not very familiar with multitasking/multithreading in D 
so any help would be appreciated.




Found my error in the following lines:


_connection = _socket.accept();
assert(_connection !is null); // this works
ubyte[] buffer;
// as blocking
auto receive = _connection.receive(buffer);


I forgot to give bugger a size. If not given, the compiler 
declares

buffer.size as 0.

receive writes data from the socket into the buffer and returns 
the length of the data. If the buffer is too small it only 
receives as much data as fits in the buffer. If the buffer is too 
small for any data it just returns with 0;

Re: [OT] Windows dying

[Joakim via Digitalmars-d]

On Monday, 6 November 2017 at 06:37:52 UTC, Tony wrote:

On Friday, 3 November 2017 at 14:12:56 UTC, Joakim wrote:
I don't know why you're so obsessed with storage when even 
midrange smartphones come with 32 GBs nowadays, expandable to 
much more with an SD card.  My tablet has only 16 GBs of 
storage, with only 10-12 actually accessible, but I've never 
had a problem building codebases that take up GBs of space 
with all the object files, alongside a 64 GB microSD card for 
many, mostly HD TV shows and movies.


The smallest storage Windows 10/Linux laptops have is a 128GB 
SSD. Even with a faster 128GB SSD being around the price of a 
1TB hard drive, I still see 1TB being the dominant low-end 
storage. So I am going by what I see being offered as a 
minimum. It may be that most or even 99% of people can get by 
with 32GB flash memory, but it isn't being offered (except on 
Chromebooks which have traditionally only been web browsers, 
and on Windows 10S machines which can only run Windows Store 
apps).


The vast majority of users would be covered by 5-10 GBs of 
available storage, which is why the lowest tier of even the 
luxury iPhone was 16 GBs until last year.  Every time I talk to 
normal people, ie non-techies unlike us, and ask them how much 
storage they have in their device, whether smartphone, tablet, or 
laptop, they have no idea.  If I look in the device, I inevitably 
find they're only using something like 3-5 GBs max, out of the 
20-100+ GBs they have available.


You only need 32 GBs or more if you're downloading a bunch of HD 
videos like I do, playing giant AAA games, or setting up a bunch 
of VMs, like some devs do.  These are all niche uses, that 99% of 
users don't partake in, which is why 32 GBs is plenty for them.


Are you suggesting they are developing their games for iOS 
and Android devices ON those devices? Apple has XCode for 
developing iOS apps and it runs on macOS machines only. There 
is also the Xamarin IDE or IDE plug-in from Microsoft that 
allows C# on iOS, but it runs on macOS or WIndows. For 
Android, there is Android Studio - "The Official IDE of 
Android" - which runs on Windows, macOS and Linux. There is 
no Android version.


Yes, of course they're still largely developing mobile games 
on PCs, though I'm not sure why you think that matters.  But 
your original claim was that they're still using PC-focused 
IDEs, as opposed to new mobile-focused IDEs like XCode or 
Android Studio, which you now highlight.


I never made any previous claim about what IDEs are being used. 
The only time I previously mentioned an IDE was with regard to 
RemObjects and Embarcadero offering cross-compilation to 
Android/iOS with their products.


"There is a case to be made for supporting  Android/iOS 
cross-compilation. But it doesn't have to come at the expense 
of Windows 64-bit integration. Not sure they even involve the 
same skillsets. Embarcadero and Remobjects both now support 
Android/iOS development from their Windows (and macOS in the 
case of Remobjects) IDEs."


That was to highlight that those two compiler companies have 
seen fit to also cross-compile to mobile - they saw an 
importance to mobile development. It wasn't about what IDEs are 
best for mobile or even what IDEs are being used for mobile.


If you look back to the first mention of IDES, it was your 
statement, "Good luck selling game developers on using D to 
develop for Android, when you can't supply those same game 
developers a top-notch development environment for the premier 
platform for performance critical games - Windows 64-bit."


That at least implies that they're using the same IDE to target 
both mobile and PC gaming, which is what I was disputing.  If you 
agree that they use completely different toolchains, then it is 
irrelevant whether D supports Windows-focused IDEs, as it doesn't 
affect mobile-focused devs.


Not that it matters, but I don't think that XCode meets the 
definition of "new mobile-focused IDE" as-as far as I know, it 
was developed for OS X development and is still used for such. 
Android Studio may be "new mobile-focused", even though based 
on IntelliJ IDEA.


Sure, they took existing IDEs and refocused them towards mobile 
development.  XCode better be focused on iOS, as that's pretty 
much all that devs are using it for these days.


Yes, Windows is dominant, dominant in a niche, internal IT.  
The consumer mobile market is much larger nowadays, and 
Windows has almost no market share there.


Sad too, because of all the tablet/phone interfaces, the only 
one that is not just "icons on a background", and my personal 
preference, is Windows Mobile.


I've always thought that flat Metro interface was best suited for 
mobile displays, the easiest to view, render, and touch.  To some 
extent, all the other mobile interfaces have copied it, with 
their move to flat UIs over the years.  However, it obviously 
takes much more than a nice GUI to do well in mobile.


As for 

Re: What is the FreeBSD situation?

[Walter Bright via Digitalmars-d]

On 11/5/2017 10:37 PM, codephantom wrote:

On Monday, 6 November 2017 at 04:56:53 UTC, Walter Bright wrote:
Interestingly, all I actually need to test the 16 bit code generation is an 
8088 emulator with some of the DOS API interrupts supported. The CPU is simple 
enough that should be easy :-)


I still have 'actual' pc's here at home, from the 90's, running MS-DOS.


I have some too, and I tried to fire them up a couple years ago. None of them 
would. Probably bad capacitors.



So, don't listen to the naysayers...there is actually a market (small as it is) 
for 'DMD for MS-DOS'.


I know.

Re: Project Elvis

[Jonathan M Davis via Digitalmars-d]

On Monday, November 06, 2017 07:10:43 bauss via Digitalmars-d wrote:
> On Monday, 6 November 2017 at 00:20:09 UTC, Neia Neutuladh wrote:
> > On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei
> >
> > Alexandrescu wrote:
> >> Walter and I decided to kick-off project Elvis for adding the
> >> homonym operator to D.
> >
> > It's easy to write in function form:
> >   auto orElse(T)(T a, lazy T b)
> >   {
> >
> > return a ? a : b;
> >
> >   }
> >
> >   writeln(args[1].length.orElse(fibonacci(50)));
> >
> > This version can also be specialized for things like Nullable,
> > where you can't necessarily cast it safely to a boolean but
> > have a check for validity.
> >
> > Is it that valuable to have an operator for it instead?
> >
> >
> > As an aside, I believe feepingcreature had a custom infix
> >
> > operator for this sort of thing defined, so you could write:
> >   (a /or/ b /or/ c).doStuff();
> >
> > The implementation (along with /and/) is left as an exercise to
> > the reader.
>
> Sure you might be able to write it easily, but pretty much
> everyone writes a function like that in their projects and you
> don\t really know the implementation always and you have to
> remember the exact name or else you end up writing the function
> yourself in your project to make sure the implementation is
> exactly like that, which in fact turns out to be re-inventing the
> wheel.
>
> By having an official syntax for it, you don't end up with code
> duplication like that and the implementation details of the
> behavior is clear.
>
> Because in some implementation "orElse()" might only check if the
> value is null and not necessary if the value is true.
>
> Ex. one might implement it like:
>
> auto orElse(T)(T a, lazy T b)
> {
>   return a !is null ? a : b;
> }
>
> Such implementation detail is not clear from the call-side.
>
> However with an official implementation you know exactly how it
> will behave and nothing is obscure like this.

That might be an argument for having an official implementation, but it's
not really an argument for why it should be built into the language; it
could just as easily be in Phobos if that's all that matters.

- Jonathan M Davis

Re: Creating a C# like Asynchronous Socket

[DrCataclysm via Digitalmars-d-learn]

On Sunday, 5 November 2017 at 14:47:37 UTC, DrCataclysm wrote:
I am trying to build something like the asynchronous Sockets 
from C# .NET but I'm stuck at the accepting phase.




The client created by _socket.accept() cannot receive any data.

client.receive() immediately returns 0 like a non-blocking 
socket. I think it has something to do with the original socket 
being owned by a different thread.


I am not very familiar with multitasking/multithreading in D so 
any help would be appreciated.


// I removed all multithreading and cleaned up the example. It 
still does not work.
// Sockets don't seem to work as class fields, is there a reason 
for this?

// Has anyone a better idea to accomplish this?

import std.socket;
import std.stdio;

void main(){
TCPListener test = new TCPListener("127.0.0.1", 9001);
test.startListening();
while (true){}
}

public class TCPListener {
ushort _port;
string _address;
bool _active;
Socket _socket = null;
Socket _connection = null;

this(string address, ushort port, string lineEnd = "\n") {
_port = port;
_address = address;
_socket = new TcpSocket();
_socket.setOption(SocketOptionLevel.SOCKET, 
SocketOption.REUSEADDR, true);

}

void startListening(){
// bind the port in the main thread
try{
assert(_socket !is null);
_socket.bind(new InternetAddress(_port));
_socket.listen(3);
}
catch (Exception e){
writeln(e.msg);
}
//auto _connectionTask = task();
//_connectionTask.executeInNewThread();
Accept();
}

private void Accept(){
bool error = false;
// start accepting in a different thread
try{
_connection = _socket.accept();
assert(_connection !is null); // this works
ubyte[] buffer;

// this does not block, even if the socket is 
explicitly markes

// as blocking
auto receive = _connection.receive(buffer);

// this always fails
assert(receive != 0);
}
catch (SocketAcceptException e){
writeln("Error while accepting connection: " ~ e.msg);
error = true;
}
finally{
//emit(error);
}
}
}