Re: The daily D riddle

[H. S. Teoh via Digitalmars-d]

On Sun, Jan 28, 2018 at 12:04:42AM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
> On Saturday, January 27, 2018 23:44:40 Jonathan M Davis via Digitalmars-d 
> wrote:
[...]
> > It does exactly what I'd expect it to do, though honestly, it's the
> > sort of thing I wish weren't legal, just like I wish that it weren't
> > legal to call a static member function via a member. Maybe there are
> > cases where it's useful, but it just seems wrong.
> 
> via in instance, I mean. IMHO, it should be required to do
> Type.staticMember rather than var.staticMember. The fact that it's
> allowed is just messy and is one of the things that we inherited from
> C++ that we shouldn't have. This case falls in the same camp, except
> that it's a new mistake, since C++ doesn't have init values.
[...]

Are you sure this came from C++? I'm pretty sure instance.staticMember
(or instance->staticMember) is not allowed in C++, you have to write
Class::staticMember. I distinctly remember, having gotten used to the
distinction in C++, being a little surprised that D was lax in this
area. In fact, I remember running into problems with my early D code
where I relied on this distinction, only to quickly find myself drowning
in overload conflicts / ambiguity errors when I tried invoking the
methods.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- 
Walter Bright

[Issue 18321] New: undefined reference to __ModuleInfoZ depending on whether module is imported directly or indirectly

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

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

  Issue ID: 18321
   Summary: undefined reference to __ModuleInfoZ depending on
whether module is imported directly or indirectly
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

dmd -oftest3 -version=B main.d
#ok

dmd -oftest3 -version=A main.d
Undefined symbols for architecture x86_64:
  "_D4foo24util12__ModuleInfoZ", referenced from:
  _D4main12__ModuleInfoZ in test3.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


```d
module main;
version(A) import foo2.util;
version(B) import foo2.util2;
void main(){fun;}

module foo2.util2;
public import foo2.util;

module foo2.util;
 void fun()(){
   // these cause the link error
   import std.path;
   //import std.file;

   /+
   // these are ok
   import std.stdio;
   import std.range;
   import std.algorithm;
   +/

 }

```

--

[Issue 18321] undefined reference to __ModuleInfoZ depending on whether module is imported directly or indirectly

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
   Severity|enhancement |normal

--

[Issue 17186] Type inference for parameters with default argument

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

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

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

   What|Removed |Added

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

--- Comment #5 from hst...@quickfur.ath.cx ---
Related:
https://issues.dlang.org/show_bug.cgi?id=17036
https://issues.dlang.org/show_bug.cgi?id=16467

--

[Issue 17036] Template default parameter does not works correctly

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

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

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

   What|Removed |Added

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Related:
https://issues.dlang.org/show_bug.cgi?id=16467
https://issues.dlang.org/show_bug.cgi?id=17186

--

Re: The daily D riddle

[Jonathan M Davis via Digitalmars-d]

On Saturday, January 27, 2018 23:44:40 Jonathan M Davis via Digitalmars-d 
wrote:
> On Sunday, January 28, 2018 08:25:51 Shachar Shemesh via Digitalmars-d
>
> wrote:
> > What will the following code print? Do not use the compiler:
> >
> > import std.stdio;
> >
> > struct A {
> >
> >   int a = 1;
> >
> >   void initialize() {
> >
> >   a = a.init;
> >
> >   }
> >
> > }
> >
> > void main() {
> >
> >   A a;
> >   a.initialize();
> >
> >   writeln(a.a);
> >
> > }
> >
> > I find this behavior unexpected.
>
> It does exactly what I'd expect it to do, though honestly, it's the sort
> of thing I wish weren't legal, just like I wish that it weren't legal to
> call a static member function via a member. Maybe there are cases where
> it's useful, but it just seems wrong.

via in instance, I mean. IMHO, it should be required to do Type.staticMember
rather than var.staticMember. The fact that it's allowed is just messy and
is one of the things that we inherited from C++ that we shouldn't have. This
case falls in the same camp, except that it's a new mistake, since C++
doesn't have init values.

- Jonathan M Davis

Re: The daily D riddle

[Timothee Cour via Digitalmars-d]

why is `a.init` even legal? (instead of typeof(a).init)
likewise the following compiles, but IMO should not:
class A{ void fun(this a){}}
(instead we should have typeof(this)

How about deprecating these lax syntaxes?
they serve no purpose (we should use typeof(...)) and can cause harm
in generic code

On Sat, Jan 27, 2018 at 10:39 PM, Ali Çehreli via Digitalmars-d
 wrote:
> On 01/27/2018 10:25 PM, Shachar Shemesh wrote:
>>
>> What will the following code print? Do not use the compiler:
>>
>> import std.stdio;
>>
>> struct A {
>>  int a = 1;
>>
>>  void initialize() {
>>  a = a.init;
>>  }
>> }
>>
>> void main() {
>>  A a;
>>  a.initialize();
>>
>>  writeln(a.a);
>> }
>>
>> I find this behavior unexpected.
>
>
> I used the compiler to check my guess and I was wrong. The following makes
> the difference:
>
> a = A.init.a;
>
> So we currently have:
>
> a.init  (type's init value)
> A.init.a(members' init value)
>
> If it were designed as you want, we would have the following:
>
> typeof(a).init  (type's init value)
> a.init  (members init value)
>
> Well, too late I guess. :)
>
> Ali

Re: The daily D riddle

[Shachar Shemesh via Digitalmars-d]

On 28/01/18 08:33, Mike Franklin wrote:

On Sunday, 28 January 2018 at 06:25:51 UTC, Shachar Shemesh wrote:

What will the following code print? Do not use the compiler:

import std.stdio;

struct A {
int a = 1;

void initialize() {
    a = a.init;
}
}

void main() {
A a;
a.initialize();

writeln(a.a);
}

I find this behavior unexpected.


Works exactly as I predicted.


Good for you.

I think the compiler should warn about such a case.

Re: The daily D riddle

[Jonathan M Davis via Digitalmars-d]

On Sunday, January 28, 2018 08:25:51 Shachar Shemesh via Digitalmars-d 
wrote:
> What will the following code print? Do not use the compiler:
>
> import std.stdio;
>
> struct A {
>   int a = 1;
>
>   void initialize() {
>   a = a.init;
>   }
> }
>
> void main() {
>   A a;
>   a.initialize();
>
>   writeln(a.a);
> }
>
> I find this behavior unexpected.

It does exactly what I'd expect it to do, though honestly, it's the sort of
thing I wish weren't legal, just like I wish that it weren't legal to call a
static member function via a member. Maybe there are cases where it's
useful, but it just seems wrong.

In any case, init goes with a type, not a variable, which is why it acts the
way it does.

- Jonathan M Davis

Re: The daily D riddle

[Ali Çehreli via Digitalmars-d]

On 01/27/2018 10:25 PM, Shachar Shemesh wrote:

What will the following code print? Do not use the compiler:

import std.stdio;

struct A {
 int a = 1;

 void initialize() {
     a = a.init;
 }
}

void main() {
 A a;
 a.initialize();

 writeln(a.a);
}

I find this behavior unexpected.


I used the compiler to check my guess and I was wrong. The following 
makes the difference:


a = A.init.a;

So we currently have:

a.init  (type's init value)
A.init.a(members' init value)

If it were designed as you want, we would have the following:

typeof(a).init  (type's init value)
a.init  (members init value)

Well, too late I guess. :)

Ali

Re: The daily D riddle

[Mike Franklin via Digitalmars-d]

On Sunday, 28 January 2018 at 06:25:51 UTC, Shachar Shemesh wrote:

What will the following code print? Do not use the compiler:

import std.stdio;

struct A {
int a = 1;

void initialize() {
a = a.init;
}
}

void main() {
A a;
a.initialize();

writeln(a.a);
}

I find this behavior unexpected.


Works exactly as I predicted.

The daily D riddle

[Shachar Shemesh via Digitalmars-d]

What will the following code print? Do not use the compiler:

import std.stdio;

struct A {
int a = 1;

void initialize() {
a = a.init;
}
}

void main() {
A a;
a.initialize();

writeln(a.a);
}

I find this behavior unexpected.

[Issue 12511] static overloaded function is not accessible

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

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

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

   What|Removed |Added

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

--

[Issue 12511] static overloaded function is not accessible

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

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

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

https://github.com/dlang/dmd/commit/0278c5138a2b9d6329b20d58e2164f13556bcda7
Fix Issue 12511 - static overloaded function is not accessible

https://github.com/dlang/dmd/commit/1928320aef174f3a4eaecc375b8ed650049084d9
Added link to issue 12511

https://github.com/dlang/dmd/commit/1b0890a76b5bc6d3c994be31ed6b8c410916b4ca
Merge pull request #7773 from RazvanN7/Issue_12511

Fix Issue 12511 - static overloaded function is not accessible
merged-on-behalf-of: Mike Franklin 

--

[Issue 17941] arity (and probably others) only consider the first lexically present function

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

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

--- Comment #3 from dechcaudron+dlang.issue.track...@protonmail.com ---
> a real solution would allow people to indicate which overload they're 
> interested in

Maybe allow something of the sort

static assert(arity!fun(int) == 1);
static assert(arity!gun(int, int) == 2);

?

I had reported this as a Phobos issue (see above), but since it has been marked
as a duplicate for a dmd one, there's not much I can do. Compiler stuff is
still magic to me, I'm afraid.

--

Re: parallelism

[thedeemon via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 20:49:43 UTC, Arun Chandrasekaran 
wrote:



Error: must use labeled break within static foreach


Just follow the compiler suggestion:

void main(string[] args) {
auto op = Operation.a;
foreach (_; 0 .. args.length) {
ops: final switch (op) {
static foreach(e; EnumMembers!Operation) {
case e:
mixin(e.to!string ~ "();");
break ops;
}
}
}
}

Here 'ops' is a label that we use to tell break what exactly it 
breaks.
But really I'm not sure why you want static foreach here, a 
simple foreach is fine, it gets unrolled statically here just 
like static one.

[Issue 16739] switch ignores case

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

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

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

https://github.com/dlang/druntime/commit/efc7377ec02c19377366bf9eb80ed7b3653b457c
add test for issue 16739 - switch ignores case

https://github.com/dlang/druntime/commit/2411c52cbc31693e0a46fa06fb592787c9634ef0
Merge pull request #2064 from aG0aep6G/16739

add test for issue 16739 - switch ignores case
merged-on-behalf-of: Andrei Alexandrescu 

--

Re: Class member function calls inside ctor and dtor

[Shachar Shemesh via Digitalmars-d]

On 28/01/18 03:13, Jonathan M Davis wrote:

On Saturday, January 27, 2018 19:42:26 Steven Schveighoffer via Digitalmars-
d wrote:

Well, a virtual function may expect that the ctor has been run, and
expect that members are different from their init values.


Yes, but you can have that problem even without getting inheritance involve.


Indeed. D's lack of proper definition of when underlying objects are 
initialized will strike you here as well.


However

Here, at least, you can view the problem locally. The problem is 100% 
contained in the constructor definition, and if it strikes you, you know 
where to look for it.


With the inherited class case, that's not so simple. I can inherit your 
class, and then you can change your class' destructor definition, and 
I'll be caught completely off guard.


A second point is that while the constructor may choose when to call the 
parent's constructor, the destructor has no such prerogative.


Finally, even if you can control when your parent is destroyed, that 
doesn't mean there is anything you can do about it. If your class 
inherently needs a functioning parent in order to do its stuff, then you 
have no choice but to call the parent's super before doing anything else 
in the constructor. If the parent then chooses to call virtual 
functions, you might be facing a problem with no tools to resolve it.


C++'s method of initializing parents is ugly as hell and a little 
confusing, but it is extremely clean and well defined. Both the compiler 
and the programmer know for sure what has been initialized, and no 
accidental calling of or relying on uninitialized members is possible.


Shachar

Re: D generates large assembly for simple function

[Ali Çehreli via Digitalmars-d-learn]

On 01/27/2018 11:42 AM, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976


According to that link D and C++ both produce 4 lines of assembly, Rust 
7, and Go 38 (for that function).


Ali

[Issue 18319] std.exception: enforce example does not compile

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

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

Seb  changed:

   What|Removed |Added

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

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

--

[Issue 17941] arity (and probably others) only consider the first lexically present function

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||dechcaudron+dlang.issue.tra
   ||ck...@protonmail.com

--- Comment #2 from Simen Kjaeraas  ---
*** Issue 18314 has been marked as a duplicate of this issue. ***

--

[Issue 18314] std.traits.getSymbolsByUDA only considers the first symbol of an overload set

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

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

--- Comment #1 from Simen Kjaeraas  ---


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

--

Re: D generates large assembly for simple function

[Seb via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:43:50 UTC, Stefan Koch wrote:

On Saturday, 27 January 2018 at 19:42:01 UTC, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976

The actual code is :
 imul edi, edi
 mov eax, edi
 ret


The rest is runtime initialization.
which you can remove using an undocumented -betterC switch.


BTW as asm.dlang.org is dead, you can use run.dlang.io for these 
things, e.g.


DMD: https://run.dlang.io/is/lLL1aJ
LDC: https://run.dlang.io/is/sVn5tu

(-output-s / -asm are only added for extra convenience)

Since a couple of days, it even does demangling of the symbols.
Though, of course, if you want to look only at LDC's output, 
godbolt is still the better choice.

Re: Class member function calls inside ctor and dtor

[Jonathan M Davis via Digitalmars-d]

On Saturday, January 27, 2018 19:42:26 Steven Schveighoffer via Digitalmars-
d wrote:
> Well, a virtual function may expect that the ctor has been run, and
> expect that members are different from their init values.

Yes, but you can have that problem even without getting inheritance involve.
For instance,

class C
{
immutable string s;

this()
{
s = foo();
}

string foo()
{
return s ~ "foo";
}
}

When foo is called from the constructor, s is null, whereas every time it's
accessed after that, it's "foo", meaning that the first time, foo returns
"foo" and all other times, it returns "foofoo". You can also do

class C
{
immutable string s;

this()
{
s = s ~ "foo";
}
}

which surprised me. I thought that the compiler prevented you from using an
immutable variable before it was assigned in the constructor, but it
doesn't. It actually can't if you call any member functions unless it
required that all const and immutable members be initialized before calling
other functions, but it could at least prevent it within the constructor. It
doesn't though.

So, you can do some weird stuff with structs or classes that have been
initialized with their init values but not had all of their constructors
run, but because D initializes the object with the init value first, at
least you get something consistent out of the deal, and there are no
problems with the wrong version of a virtual function being called, because
the object was only partially constructed, whereas in C++, you can end up
crashing the program due to stuff like calling an abstract function that's
only defined in derived classes.

- Jonathan M Davis

Re: assert and enforce both compiled out with -release

[Ali Çehreli via Digitalmars-d-learn]

On 01/27/2018 04:59 PM, lobo wrote:
> On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:
>> On 01/27/2018 10:33 AM, kdevel wrote:
>>
>>> I suggest the deletion of the sentence "Use assert in contracts."
>>
>> Done.
>>
>> Ali
>
> Wait, no this isn't right, is it?

It is right because that statement made one person to replace 'enforce's 
with 'asserts's.


> Enforce should not be used in
> contracts so the "Use assert in contracts" statement is correct and
> should remain.

I don't think enforce documentation is the right place to get into such 
matters. Warning against a potential misuse is fine but hinting at 
"correct use of assert vs. enforce" is not only distracting but also 
misguiding.


> I think the issue here is the OP is getting confused
> between assert vs. exception.
>
> Contracts (in D) are used to define and assert the agreed logic
> behaviour of the program code.
>
> Asserts catch logic bugs in the code that may lead to incorrect
> behaviour at runtime. Exceptions are for exceptional cases that crop up
> at runtime due to factors external to the code logic, e.g. invalid
> external state such as failing to open a file or a sensor not going off
> when it should because it is faulty.
>
> Asserts can be removed in -release code because it is assumed the logic
> has been asserted correct during debug builds and testing. The same
> reason compilers now are starting to optimise out code based on assert
> conditions.
>
> bye,
> lobo

All true.

Ali

Re: D generates large assembly for simple function

[Seb via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:43:50 UTC, Stefan Koch wrote:

On Saturday, 27 January 2018 at 19:42:01 UTC, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976

The actual code is :
 imul edi, edi
 mov eax, edi
 ret


The rest is runtime initialization.
which you can remove using an undocumented -betterC switch.


It's not undocumented:

https://dlang.org/spec/betterc.html

[Issue 17832] std.random.choice cannot be used with other random generators

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

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

Seb  changed:

   What|Removed |Added

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

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

--

Re: assert and enforce both compiled out with -release

[lobo via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 22:53:37 UTC, Ali Çehreli wrote:

On 01/27/2018 10:33 AM, kdevel wrote:

I suggest the deletion of the sentence "Use assert in 
contracts."


Done.

Ali


Wait, no this isn't right, is it? Enforce should not be used in 
contracts so the "Use assert in contracts" statement is correct 
and should remain. I think the issue here is the OP is getting 
confused between assert vs. exception.


Contracts (in D) are used to define and assert the agreed logic 
behaviour of the program code.


Asserts catch logic bugs in the code that may lead to incorrect 
behaviour at runtime. Exceptions are for exceptional cases that 
crop up at runtime due to factors external to the code logic, 
e.g. invalid external state such as failing to open a file or a 
sensor not going off when it should because it is faulty.


Asserts can be removed in -release code because it is assumed the 
logic has been asserted correct during debug builds and testing. 
The same reason compilers now are starting to optimise out code 
based on assert conditions.


bye,
lobo

Re: How programmers transition between languages

[bachmeier via Digitalmars-d]

On Saturday, 27 January 2018 at 20:15:51 UTC, aberba wrote:
There have been several complaints about tools, and certain 
important stuff missing in the standard library (HTTP/HTTP2, 
rpc, etc) and no 'official' response or some blog post from 
them about it (whether they even care).


The community will have to do this. If Walter and Andrei were 
interested in it, they'd have been working on it long ago. They 
have way too much to do the way it is, and as soon as it becomes 
official, there are rules and rules about rules and six levels of 
bureaucracy.

[Issue 18208] ddemangle RangeError@src/core/demangle.d(230)

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
just ran into that why doing:
git clone https://github.com/dlang-community/D-Scanner && cd D-Scanner && dub
build && nm bin/dscanner|ddemangle

After reduction here's a symbol that triggers (see below).

In addition to fixing this bug, we should make demangle inner loop protected
via a try/catch so that demangle keeps going till end of stdin, and then
rethrow error at the end (at least as an option ddemangle
--keep-going-on-error)


```
echo
_D3std4conv__T10emplaceRefTSQBa12experimental5lexer__T14TokenStructureThVAyaa305_0a20202020737472696e6720636f6d6d656e743b0a20202020737472696e6720747261696c696e67436f6d6d656e743b0a0a20202020696e74206f70436d702873697a655f7420692920636f6e73742070757265206e6f7468726f77204073616665207b0a202020202020202069662028696e646578203c2069292072657475726e202d313b0a202020202020202069662028696e646578203e2069292072657475726e20313b0a202020202020202072657475726e20303b0a202020207d0a0a20202020696e74206f70436d702872656620636f6e737420747970656f66287468697329206f746865722920636f6e73742070757265206e6f7468726f77204073616665207b0a202020202020202072657475726e206f70436d70286f746865722e696e646578293b0a202020207d0aZQYoTQZtTQZxZQBAoFKQBAhKQBAmZ1S11__xopEqualsFKxSQBCjQBCj__TQBCiTQBCaTQBCfTQBCkZQBDcFKQBCvKQBDaZQCoKxQCbZb
| ddemangle
core.exception.RangeError@src/core/demangle.d(230): Range violation

4   ddemangle   0x000104b1fece _d_arrayboundsp +
110
5   ddemangle   0x000104b18ad7 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.append(const(char)[]) +
483
6   ddemangle   0x000104b18c0d pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.put(const(char)[]) +
129
7   ddemangle   0x000104b1d28a pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseValue(char[],
char) + 1574
8   ddemangle   0x000104b1ded8 pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseTemplateArgs() +
652
9   ddemangle   0x000104b1e69e pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseTemplateInstanceName(bool)
+ 282
10  ddemangle   0x000104b1e9be pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseSymbolName() + 162
11  ddemangle   0x000104b1eca0 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseQualifiedName() +
68
12  ddemangle   0x000104b1ad82 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]) +
3558
13  ddemangle   0x000104b1bdcf pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]).__lambda4()
+ 19
14  ddemangle   0x000104b1bccb pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]).parseBackrefType(scope
char[] delegate() pure @safe) + 263
15  ddemangle   0x000104b1a036 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]) + 154
16  ddemangle   0x000104b1c8ac pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseFuncArguments() +
760
17  ddemangle   0x000104b1ebd2 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseFunctionTypeNoReturn(bool)
+ 374
18  ddemangle   0x000104b1ecaa pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseQualifiedName() +
78
19  ddemangle   0x000104b1ad82 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]) +
3558
20  ddemangle   0x000104b1a1d2 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseType(char[]) + 566
21  ddemangle   0x000104b1c8ac pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseFuncArguments() +
760
22  ddemangle   0x000104b1ebd2 pure @safe char[]
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseFunctionTypeNoReturn(bool)
+ 374
23  ddemangle   0x000104b1ee82 pure @safe void
core.demangle.Demangle!(core.demangle.NoHooks).Demangle.parseMangledName(bool,
ulong) + 374
24  ddemangle   0x000104b1f469 pure nothrow @safe
char[]

Re: Class member function calls inside ctor and dtor

[Steven Schveighoffer via Digitalmars-d]

On 1/27/18 12:01 PM, Jonathan M Davis wrote:

On Saturday, January 27, 2018 16:18:26 Thomas Mader via Digitalmars-d wrote:

On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:

I'm working on devirtualization and for that it's crucial to
know some spec details (or define them in the spec if they
aren't yet).

Currently, calling non-final member functions in the destructor
is allowed and these indirect calls are to the possibly
overridden functions of derived classes. That is, inside a base
class constructor, the object's type is its final type (so
possibly of a derived class). This is the same in the
destructor. Thus, the object's dynamic type does not change
during its lifetime.


Can't answer your question but have a little question.
How is the behavior different to the situation in C++? They argue
that it's not good to call virtual methods in Con-/Destructors in
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-ctor-virtu
al

So I guess it should better be not used in D as well?


D solved that problem. In C++, when you're in the base class constructor,
the object doesn't have its derived type yet. It's still just the base
class. Each class level gets add as it's constructed (the same in reverse
with the destructor). You don't have a full object until all constructors
have been run, and once you start running destructors, you don't have a full
class anymore either.

In D, on the other hand, the object is initialized with its init value
_before_ any constructors are run. So, it's a full object with a full type,
and everything virtual is going to get the type right.


Well, a virtual function may expect that the ctor has been run, and 
expect that members are different from their init values.


However, because you can initialize that data before calling the 
superclass' constructor, you can alleviate this problem as well.


For instance, the invariant may be called when you call the virtual 
function:


import std.stdio;

class A
{
this() { writeln("A.ctor"); foo(); }
void foo() { writeln("A.foo"); }
}

class B : A
{
int x;
this() {
writeln("B.ctor");
x = 1; // note the intialization before calling the base class
super();
}
invariant {
writeln("invariant!");
assert(x == 1);
}
override void foo() { writeln("B.foo"); }
}

void main()
{
auto b = new B;
}

output:
B.ctor
A.ctor
invariant! <- before calling foo
B.foo
invariant! <- after calling foo
invariant! <- after constructors are done

-Steve

[Issue 17036] Template default parameter does not works correctly

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|Template default parametr   |Template default parameter
   |does not works correctly|does not works correctly

--- Comment #3 from Seb  ---
Here's another example:


```
struct Foo {}
struct Bar {}

Foo foo;

void myFun(D)(D d = foo){}

void bar()
{
myFun(); // works
myFun(Bar()); // error
}
```

--

[Issue 16739] switch ignores case

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords|wrong-code  |
  Component|dmd |druntime
 Resolution|WORKSFORME  |FIXED

--- Comment #5 from ag0ae...@gmail.com ---
Apparently this was actually a Druntime bug, and it was fixed by
https://github.com/dlang/druntime/pull/1952

New PR for the test:
https://github.com/dlang/druntime/pull/2064

--

Re: How programmers transition between languages

[rjframe via Digitalmars-d]

On Sat, 27 Jan 2018 22:59:17 +, Ola Fosheim Grostad wrote:

> On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
>> If you use an IDE or analysis/lint tool, you'll get type checking. The
>> interpreter will happily ignore those annotations.
> 
> You need to use a type checker to get type checking... No surprise
> there, but without standard type annotations the type checker isn't all
> that useful.  Only in past few years have typing stubs become available
> for libraries, and that makes a difference,

My point is that the interpreter ignores information that I give it, when 
that information clearly proves that I have a bug. Python 3.6 gives you an 
explicit type system when you want/need it, but stops just short of making 
it actually useful without secondary tools.

Granted, everybody should be using those tools on decent-sized projects 
anyway, but the interpreter shouldn't be ignoring obvious issues. If I 
explicitly label a type, implicit casts/overrides/replacements should not 
be accepted, no matter how dynamic the type system. The feature was 
designed for tools; they failed to design it for programmers as well.

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny via Digitalmars-d]

On Saturday, 27 January 2018 at 22:58:27 UTC, H. S. Teoh wrote:
I never said we should not offer good IDE support, in fact I 
said that we *need* good IDE support.  But that in no way 
justifies the wrong claim that you can't be productive without 
an IDE. In fact, I find myself *more* productive without 
needing a memory-hogging, CPU-hogging GUI program that requires 
taking my hands off the keyboard all the time, just to edit 
code. But I'm sure you think the same about Vim/Emacs, so we're 
square. :-)


The problem is Teoh that learning a language in Vim or a IDE are 
two totally different things.


I used to program in Notepad because i grew up with PHP and knew 
it like the back of my hand. The result was very little need to 
see the documentation. The moment i found PHPStorm, i fell in 
love. Fast function jumping, remote tools, database at your 
fingertips, code checkers and hinters and all the other niceties.


But for anybody who is not a master of a language or even 
intermediate, a good IDE can make one so much more productive 
compared to the same person just relying on a default notepad 
type environment. The fact that a good IDE expands the methods 
from a class, it shows you the basic help / buildup of the 
methods calls so you know exactly where you write what, without 
the need to visit the developers documentation website.


It massif increases the adoption rate of a language, when your 
new to a language or not a 10 year expert.


And for the people who are used to a language, a IDE can still be 
useful by increasing productivity as you simply do ... example 
"fu" ... enter ... "function " or automated braked closing, or 
error indicators when you forget something so you do not wast 
your time discovering a stupid issue during compilation.


Its the same issue i personally have with languages that get lazy 
and trow out readability in exchange for less keystrokes. You can 
at times tell what development ides a language uses simply by 
looking at the language. Everything awkwardly shortcut like "fn" 
and other shorthand ( but what do make it much more brain taxing 
for anybody new ).


Advanced programmers have the skills to make new languages, 
unlike beginner programmers but they also are so used to a 
specific environment that they build up to speed up, over the 
year, that they assume that everybody else can get going just as 
fast as they are.


As a side note, despite working years in Vim, i still prefer a 
normal but well equip IDE because there are just some things VIM 
is not good at ( unless you customize it to hell with 100's of 
plugins what tends to take years to find your sweet spot and 
build up the know how to use them all perfectly ). VIM with all 
the plugins is simply a IDE, just one where you do not move your 
hands too much away from the keyboard. As your example of your 
colleagues: a IDE where it takes ages to jump to a definition in 
a file, is simply a incomplete IDE. Or maybe those colleges have 
not master the IDE. I know for a fact from myself that there is a 
massive amount of things still "hiding" in Jetbrain there 
products or Visual Studio Code that can make me more productive 
but you learn over time or when you stumble upon it.


From my point of view, without a working IDE its much more 
difficult for a non-specific-language to learn and get better at 
the language. And again, VIM with the right plugins is a IDE, 
simple as that. Its annoying that people do not see this. The big 
difference is that VIM is designed around not moving your hand to 
your mouse and that is its major strength.


On a side note: The issue i had with the plugins, well one of the 
plugin authors found the issue and it came down to it that the D 
compiler had a regression that effect DCD. I remember mentioning 
before as how many times the compiler ends up breaking code.


Going over the D release list, you see way too many times: Major 
release - fix - fix, Major release - fix,  Major release - fix - 
fix... What indicates to me a lack of cross platform testing. 
Especially the amount of regressions surprises even me. It feels 
like too much focus is put upon new features and too few upon a 
test setup that does not only tests the compiler but also all the 
dub packages.

Re: String Switch Lowering

[H. S. Teoh via Digitalmars-d]

On Sat, Jan 27, 2018 at 03:48:19PM -0800, Timothee Cour wrote:
[...]
> eg `ldc -hash-threshold` would be 1 option.
[...]
> with a small threshold:
> 
> mangled:
> _D8analysis3run__T9shouldRunℂ0abf2284dd3
> 
> demangled:
> pure nothrow @nogc @safe immutable(char)[] analysis.run.shouldRun.ℂ0abf2284dd3
> 
> The `ℂ` symbol indicating hashing was applied because symbol size
> exceed threshold.
> The demangled version also would have that. A separate file (dmd
> -mangle_map=file) could be produced in the rare case a user wants to
> see the full 17KB mangled and demangled symbols mapped by ℂ0abf2284dd3
[...]

This gives me an idea.  A lot of the recent complaints about symbol size
appears to be coming from templates with string template arguments, and
encoding strings inside a symbol tend to quickly make its length
explode.  What if we changed the mangling scheme such that if a string
template argument exceeds a certain length, or if the number of string
arguments (or their accumulated length) exceeds a certain size, we hash
the string arguments instead, and use the hash in the symbol instead of
encoding the raw strings themselves?

Regardless, *some* form of symbol compression is necessary in D,
especially now that druntime is also moving in the direction of more
templated code. Rainer's backref patch helped in one common use case
(chained range functions), but the string argument case remains a source
of major symbol bloat.

I was also talking with Stefan Koch on github that we need to take up a
project to improve the way dmd handles templates. There's much room for
improvement, and with D's focus on heavy-duty compile-time features,
this is a major area where we can reap large benefits for the effort
invested.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!

Re: String Switch Lowering

[Timothee Cour via Digitalmars-d]

* This has nothing to do with name mangling.

Yes and no, these things are coupled. We can improve the situation by
forcing the size of mangled and demangled symbols to be < threshold,
eg `ldc -hash-threshold` would be 1 option.

example:

current mangled:
_D8analysis3run__T9shouldRunVAyaa20_666c6f61745f6f70657261746f725f636865636bZQChFQCaKxSQDh6config20StaticAnalysisConfigZ__T9__lambda4TQEbZQpFNaNbNiNfQEqZQEu

current demangled:
pure nothrow @nogc @safe immutable(char)[]
analysis.run.shouldRun!("float_operator_check").shouldRun(immutable(char)[],
ref 
const(analysis.config.StaticAnalysisConfig)).__lambda4!(immutable(char)[]).__lambda4(immutable(char)[])

with a small threshold:

mangled:
_D8analysis3run__T9shouldRunℂ0abf2284dd3

demangled:
pure nothrow @nogc @safe immutable(char)[] analysis.run.shouldRun.ℂ0abf2284dd3

The `ℂ` symbol indicating hashing was applied because symbol size
exceed threshold.
The demangled version also would have that. A separate file (dmd
-mangle_map=file) could be produced in the rare case a user wants to
see the full 17KB mangled and demangled symbols mapped by ℂ0abf2284dd3


On Sat, Jan 27, 2018 at 3:12 PM, H. S. Teoh via Digitalmars-d
 wrote:
> On Sat, Jan 27, 2018 at 09:22:07PM +, timotheecour via Digitalmars-d 
> wrote:
> [...]
>> ```
>> 28  dscanner0x00010d59f428 @safe void
>> std.getopt.getoptImpl!(std.getopt.config, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], immutable(char)[]*,
>> immutable(char)[], immutable(char)[]*, immutable(char)[], bool*,
>> immutable(char)[], immutable(char)[][]*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*).getoptImpl(ref immutable(char)[][], ref std.getopt.configuration, ref
>> std.getopt.GetoptResult, ref std.getopt.GetOptException,
>> void[][immutable(char)[]], void[][immutable(char)[]], std.getopt.config,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
>> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], immutable(char)[]*, immutable(char)[],
>> immutable(char)[]*, immutable(char)[], bool*, immutable(char)[],
>> immutable(char)[][]*, immutable(char)[], bool*, immutable(char)[], bool*,
>> immutable(char)[], bool*, immutable(char)[], bool*) + 460
>> ```
>>
>> https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ doesn't
>> seem to help in cases like that
>
> This has nothing to do with name mangling. The mangling itself may be
> relatively small (and probably is, judging from the amount of repetition
> in the signature above), but what you're looking at is the *demangled*
> identifier. That's going to be big no matter what, unless we
> fundamentally change the way getopt() is implemented.
>
> I proposed a compile-time introspected getopt() replacement before, only
> to get laughed at by Andrei.  So I guess that means, don't expect to see
> that in Phobos anytime soon.  But I might post the code on github
> sometime for those who would benefit from it.  Basically, instead of
> taking a ridiculously long argument list, you create a struct whose
> members (together with some UDAs) define what the options are, any
> associated help text, etc., and just call it with the struct type as
> argument.  It does its thing, and returns the struct populated with the
> values retrieved from the command-line.  There are a few more features,
> but that's the gist of it.
>
>
> T
>
> --
> There is no gravity. The earth sucks.

[Issue 16467] templated function default argument take into account when not needed

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

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

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

   What|Removed |Added

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

--

Re: String Switch Lowering

[H. S. Teoh via Digitalmars-d]

On Sat, Jan 27, 2018 at 09:22:07PM +, timotheecour via Digitalmars-d wrote:
[...]
> ```
> 28  dscanner0x00010d59f428 @safe void
> std.getopt.getoptImpl!(std.getopt.config, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], immutable(char)[]*,
> immutable(char)[], immutable(char)[]*, immutable(char)[], bool*,
> immutable(char)[], immutable(char)[][]*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*).getoptImpl(ref immutable(char)[][], ref std.getopt.configuration, ref
> std.getopt.GetoptResult, ref std.getopt.GetOptException,
> void[][immutable(char)[]], void[][immutable(char)[]], std.getopt.config,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*, immutable(char)[],
> bool*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], immutable(char)[]*, immutable(char)[],
> immutable(char)[]*, immutable(char)[], bool*, immutable(char)[],
> immutable(char)[][]*, immutable(char)[], bool*, immutable(char)[], bool*,
> immutable(char)[], bool*, immutable(char)[], bool*) + 460
> ```
> 
> https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ doesn't
> seem to help in cases like that

This has nothing to do with name mangling. The mangling itself may be
relatively small (and probably is, judging from the amount of repetition
in the signature above), but what you're looking at is the *demangled*
identifier. That's going to be big no matter what, unless we
fundamentally change the way getopt() is implemented.

I proposed a compile-time introspected getopt() replacement before, only
to get laughed at by Andrei.  So I guess that means, don't expect to see
that in Phobos anytime soon.  But I might post the code on github
sometime for those who would benefit from it.  Basically, instead of
taking a ridiculously long argument list, you create a struct whose
members (together with some UDAs) define what the options are, any
associated help text, etc., and just call it with the struct type as
argument.  It does its thing, and returns the struct populated with the
values retrieved from the command-line.  There are a few more features,
but that's the gist of it.


T

-- 
There is no gravity. The earth sucks.

[Issue 18320] New: forum.dlang.org email client should include url pointing to forum msg at bottom of each email, cf github issues

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

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

  Issue ID: 18320
   Summary: forum.dlang.org email client should include url
pointing to forum msg at bottom of each email, cf
github issues
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

when reading github notifications (eg someone replied on an issue i'm
subscribed to) in gmail, I get at the bottom of the msg something like:
```
You are receiving this because you were mentioned.
Reply to this email directly, [view it on GitHub](url ...), or [mute the
thread](...).
``

could we have something similar for emails from forum.dlang.org  (cf Seb via
Digitalmars-d  via gmail.com )

This is quite convenient to go back to forum without having to search msg in
forum.dlang.org, or to share the link with someone.

--

Re: String Switch Lowering

[Timothee Cour via Digitalmars-d]

but this should be handled at the compiler level, with no change in
standard library getopt, eg using a hashing scheme (cf `ldc
-hashthres`)

On Sat, Jan 27, 2018 at 2:38 PM, Kagamin via Digitalmars-d
 wrote:
> IIRC several years ago somebody created a dub package with DbI getopt. I
> think it wouldn't suffer from this issue.

Re: D generates large assembly for simple function

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

On Sat, Jan 27, 2018 at 07:41:21PM +, Matt via Digitalmars-d-learn wrote:
> Playing around with Godbolt, D seems to generate an embarassing amount
> of assembly for a simple function (50ish for squaring an int vs 4 for
> C++ and 7 for Rust). Even Go compiles to less assembly.
> 
> Is there something I'm missing?

If you're looking for efficiency of generated code, use gdc or ldc.
While dmd is the reference compiler with the latest and greatest
bleeding-edge features, it's not known to be the best at generating
optimized code, even if you run it with -O.  If code size / efficiency
is important to you, I highly recommend using gdc or ldc instead.


T

-- 
Век живи - век учись. А дураком помрёшь.

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[H. S. Teoh via Digitalmars-d]

On Sat, Jan 27, 2018 at 06:18:02PM +, Dgame via Digitalmars-d wrote:
[...]
> It's nice that this works for you, but I strongly believe that most of
> the programmers who are willing to try something new are younger and I
> also think that most of them don't use VIM/Emacs on a daily basis.
> It's impressive that you can do it and I'm sure it works for you
> pretty well, but I doubt that younger programmers do the same - the
> hurdle to work with those tools is way to high at the start.

You know, before I started using Vim, I hated it and found it difficult
and counterintuitive to use. Then one day my then-boss convinced me to
give it an honest try.  I did, and I still hated it... but I kept at it,
and as time went by, it started to "click", and suddenly it dawned on me
that it's not "just" an editor; it's an *editing language*.  Then new
vistas opened up to me, that allowed me to things like routinely edit
8000-line source files without getting lost, and to do so far more
efficiently than any GUI can ever hope to be.  Even today, I'm learning
new things to do with it that can improve my productivity even more.
I'd never go back to my babyish days of point-and-grunt.  Was it an easy
learning curve? I won't lie -- it's not. It takes time and dedication,
something this coddled generation seems unable to grasp, it seems. But
the rewards far outweigh the investment.


> One of our programmers use VIM too, but on a regular basis he has
> problems like finding/renaming files/variables or optimize imports or
> code formatting.  I bet you can do that with the right tools and a lot
> of time as good as an IDE can do it, but the IDE can do that out of
> the box without consuming your time.

This sounds to me like inexperience.  If one doesn't know the ins and
outs of his tools, it's not surprising that he has trouble being
efficient at doing his work.

I use ctags with vim, and it's amazingly efficient: two keystrokes and
I'm right at the right file in the right place on top of the definition
of an identifier. Less than 1 second.  Yet when I work with my coworker,
who uses a fancy GUI-based IDE, he has pull up the search function,
re-type the identifer that the cursor is already sitting on, then wait
for the thing to slowly churn through 50,000 source files looking for a
pattern match, then reach for the mouse and drag the scrollbar down a
long list of possible matches, then open the file, then navigate to the
right place in the file. An order of magnitude slower.

Of course, having said that, some of my *other* coworkers who also use
vim are equally slow, if not slower, because they haven't learnt how to
use it to the max. As I said, that says to me "inexperience" rather than
"the tool sux".

As for renaming files, what has that got to do with Vim?  It's just
ctrl-Z, `mv orig.d dest.d`. Maybe followed by `git add dest.d`. Two
seconds max.  Again, being unable to work with the OS efficiently is not
a sign of an inherent flaw of the OS, just the inexperience of the user.


> It's like I said - if you mainly used VIM/Emacs you think everything
> is fine and would not try an IDE - but that's not what nowadays
> happens to new programmers. And to make D appealing to them, D has to
> offer good IDE support or it will remain as a hobby language with very
> few exceptions.

I never said we should not offer good IDE support, in fact I said that
we *need* good IDE support.  But that in no way justifies the wrong
claim that you can't be productive without an IDE. In fact, I find
myself *more* productive without needing a memory-hogging, CPU-hogging
GUI program that requires taking my hands off the keyboard all the time,
just to edit code. But I'm sure you think the same about Vim/Emacs, so
we're square. :-)

To each his own.


T

-- 
Music critic: "That's an imitation fugue!"

Re: How programmers transition between languages

[Ola Fosheim Grostad via Digitalmars-d]

On Saturday, 27 January 2018 at 13:56:35 UTC, rjframe wrote:
If you use an IDE or analysis/lint tool, you'll get type 
checking. The interpreter will happily ignore those annotations.


You need to use a type checker to get type checking... No 
surprise there, but without standard type annotations the type 
checker isn't all that useful.  Only in past few years have 
typing stubs become available for libraries, and that makes a 
difference,

Re: assert and enforce both compiled out with -release

[Ali Çehreli via Digitalmars-d-learn]

On 01/27/2018 10:33 AM, kdevel wrote:


I suggest the deletion of the sentence "Use assert in contracts."


Done.

Ali

Re: String Switch Lowering

[Kagamin via Digitalmars-d]

IIRC several years ago somebody created a dub package with DbI 
getopt. I think it wouldn't suffer from this issue.

Re: LDC 1.7.0

[aberba via Digitalmars-d-announce]

On Saturday, 27 January 2018 at 21:37:08 UTC, aberba wrote:

On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce LDC 1.7. The 
highlights of this version in a nutshell:


* Based on D 2.077.1.
* Catching C++ exceptions supported on Linux and Windows.
* LLVM for prebuilt packages upgraded to v5.0.1.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.7.0


Thanks to all contributors!


Ubuntu 16.04 still has version 1.0.0 in its repository. Why is 
it not updated anymore?


Sorry. its Compiler version 1.1.1 based on dmd v2.071.2, LLVM 
3.9.1. I expected compiler version 1.7.0 which is the latest.

Re: LDC 1.7.0

[aberba via Digitalmars-d-announce]

On Saturday, 6 January 2018 at 01:19:14 UTC, kinke wrote:

Hi everyone,

on behalf of the LDC team, I'm glad to announce LDC 1.7. The 
highlights of this version in a nutshell:


* Based on D 2.077.1.
* Catching C++ exceptions supported on Linux and Windows.
* LLVM for prebuilt packages upgraded to v5.0.1.

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.7.0


Thanks to all contributors!


Ubuntu 16.04 still has version 1.0.0 in its repository. Why is it 
not updated anymore?

[Issue 18316] std.net.curl.SMTP.mailTo fails to compile

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

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

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

https://github.com/dlang/phobos/commit/80f4709a980f9b5899b46063aa926e33bd2426bf
Fix Issue 18316 - std.net.curl.SMTP.mailTo fails to compile

https://github.com/dlang/phobos/commit/5e04cb855f7dbf34ed42e5af1ddb6316f9aca157
Merge pull request #6079 from shoo/fix_Issue18316

Fix Issue 18316 - std.net.curl.SMTP.mailTo fails to compile

--

Re: std_exception.html#enforce: example does not compile

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 20:33:46 UTC, Jonathan M Davis 
wrote:

Shall I file a bug report?


Yes.


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

[Issue 18319] New: std.exception: enforce example does not compile

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

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

  Issue ID: 18319
   Summary: std.exception: enforce example does not compile
   Product: D
   Version: D2
  Hardware: Other
OS: Other
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

The code

```
auto f = enforce(fopen("data.txt"));
auto line = readln(f);
enforce(line.length, "Expected a non-empty line.");
```

from

- https://dlang.org/phobos/std_exception.html#enforce, and
- https://dlang.org/library/std/exception/enforce.html

does not compile in any way.

https://forum.dlang.org/thread/ijtvcytskeswqtmlf...@forum.dlang.org#post-mailman.2691.1517085253.9493.digitalmars-d-learn:40puremagic.com

--

Re: String Switch Lowering

[timotheecour via Digitalmars-d]

On Saturday, 27 January 2018 at 10:38:46 UTC, Kagamin wrote:

dmd


see also this horrendous stacktrace when calling getopt with a 
bad argument:


full stacktrace:

https://gist.github.com/timotheecour/d6b623bd3d223f5d958cd86adffd7807

just 1 line of this stacktrace:

```
28  dscanner0x00010d59f428 @safe 
void std.getopt.getoptImpl!(std.getopt.config, immutable(char)[], 
bool*, immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], immutable(char)[]*, immutable(char)[], 
immutable(char)[]*, immutable(char)[], bool*, immutable(char)[], 
immutable(char)[][]*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*).getoptImpl(ref immutable(char)[][], ref 
std.getopt.configuration, ref std.getopt.GetoptResult, ref 
std.getopt.GetOptException, void[][immutable(char)[]], 
void[][immutable(char)[]], std.getopt.config, immutable(char)[], 
bool*, immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], immutable(char)[]*, immutable(char)[], 
immutable(char)[]*, immutable(char)[], bool*, immutable(char)[], 
immutable(char)[][]*, immutable(char)[], bool*, 
immutable(char)[], bool*, immutable(char)[], bool*, 
immutable(char)[], bool*) + 460

```

https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ 
doesn't seem to help in cases like that

Re: DMD as a library package can now run through all semantic phases

[Jacob Carlborg via Digitalmars-d]

On 2018-01-27 01:47, timotheecour wrote:

Invalid source/import path: 
/Users/timothee/.dub/packages/dmd-master/dmd/generated/dub
core.exception.AssertError@../../../../../.dub/packages/dmd-master/dmd/src/dmd/frontend.d(208): 
No valid config found.


Note that you don't *need* to use "findImportPaths". You can specify the 
import paths yourself, it's a library after all.


--
/Jacob Carlborg

[Issue 8864] Simpler syntax for array literal of structs from one argument

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WONTFIX

--- Comment #5 from Andrei Alexandrescu  ---
This is a core language change with many risks associated. A DIP would need to
discuss them all.

Workarounds are possible with library code:

void main() {
BigInt[] data1 = makeArray!BigInt(5, 6, 9);
Ranged!(int,5,10)[] data2 = makeArray!(Ranged!(int,5,10))(5, 6, 9);
Nibble[] data3 = makeArray!Nibble[1, 2, 15]; // Nibble.sizeof == 1
alias Typedef!int Mint;
Mint[] data4 = makeArray!Mint(5, 6, 9);
}

Within the current language this is possible although not super handy:

BigInt[] data1 = only(5, 6, 9).map!(x => BigInt(x)).array;

--

Re: rdmd main.d leads to Segmentation fault

[Kagamin via Digitalmars-d-learn]

On Friday, 26 January 2018 at 22:40:29 UTC, Timoses wrote:

Program received signal SIGSEGV, Segmentation fault.
0x00432e04 in _d_dso_registry ()
(gdb) bt
#0  0x00432e04 in _d_dso_registry ()
#1  0x00431c63 in ?? ()
#2  0x0045c08b in __libc_csu_init ()
#3  0xb7d8e206 in __libc_start_main (main=0x431c24 , 
argc=1, argv=0xb784,
init=0x45c040 <__libc_csu_init>, fini=0x45c0a0 
<__libc_csu_fini>,
rtld_fini=0xb7feb080 <_dl_fini>, stack_end=0xb77c) at 
../csu/libc-start.c:247

#4  0x004315c1 in _start ()



Any ideas?


What `disas` command shows at the point of failure?

Re: D generates large assembly for simple function

[Johan Engelen via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:45:35 UTC, Stefan Koch wrote:


ah ... -betterC is only for dmd.


`-betterC` works from LDC 1.1.0.

- Johan

Re: parallelism

[Arun Chandrasekaran via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 17:54:53 UTC, thedeemon wrote:
On Saturday, 27 January 2018 at 11:19:37 UTC, Arun 
Chandrasekaran wrote:

Simplified test case that still errors:


You got really close here. Here's a working version:

enum Operation {
a,
b
}

import std.traits, std.conv, std.stdio;

void main(string[] args) {
auto op = Operation.a;
foreach (_; 0 .. args.length) {
final switch (op) {
foreach(e; EnumMembers!Operation) {
case e:
mixin(e.to!string ~ "();");
break;
}
}
}
}

void a() { writeln("A!"); }
void b() { writeln("B!"); }


Thanks, that did the trick.

How to use break inside a static foreach? Changing the above 
foreach each to static gives the following error:


Error: must use labeled break within static foreach

Re: std_exception.html#enforce: example does not compile

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 20:11:29 kdevel via Digitalmars-d-learn wrote:
> On Saturday, 27 January 2018 at 18:34:35 UTC, Jonathan M Davis
>
> wrote:
> >> The example still does not compile.
> >
> > That has nothing to do with enforce. std.stdio.readln does not
> > take a FILE*. In general, you shouldn't mix core.stdc.stdio and
> > std.stdio.
>
> The code is from the official documentation:
>
> - https://dlang.org/phobos/std_exception.html#enforce, and
> - https://dlang.org/library/std/exception/enforce.html
>
> Shall I file a bug report?

Yes. Any time that code in the official docs doesn't compile, please report
it. In most cases, the examples in the documentation are ddoc-ed unittest
blocks, which catches such problems, but they aren't always.

- Jonathan M Davis

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[JN via Digitalmars-d]

On Saturday, 27 January 2018 at 18:18:02 UTC, Dgame wrote:
One of our programmers use
VIM too, but on a regular basis he has problems like 
finding/renaming files/variables or optimize imports or code 
formatting. I bet you can do that with the right tools and a 
lot of time as good as an IDE can do it, but the IDE can do 
that out of the box without consuming your time. It's like I 
said - if you mainly used VIM/Emacs you think everything is 
fine and would not try an IDE - but that's not what nowadays 
happens to new programmers. And to make D appealing to them, D 
has to offer good IDE support or it will remain as a hobby 
language with very few exceptions.


I think it depends on what we consider good IDE support. We can 
use C++ as baseline, so syntax highlighting, code completion and 
debugging. Or we can take it a level higher, and go into Java/C# 
territory, with stuff like automatic variable renaming across the 
entire project, extracting fields into class etc.


While I think D IDEs, when they work, aren't that much behind C++ 
IDEs (never really tried debugging D though), but they don't 
really have a chance with Java/C# IDEs and probably never will. 
Given how dynamic D can be with CTFE/mixins, you can't do the 
kind of safe refactoring that those IDEs allow. The same applies 
to C++, Rust, and probably Go as well.

Re: D generates large assembly for simple function

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:43:50 UTC, Stefan Koch wrote:

On Saturday, 27 January 2018 at 19:42:01 UTC, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976

The actual code is :
 imul edi, edi
 mov eax, edi
 ret


Could you please paste the source code? I mean in say 5 years 
when there will be no more godbolt.org someone reading this 
thread will not know what it was about.

Re: How programmers transition between languages

[aberba via Digitalmars-d]

On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote:
On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad 
wrote:
While this analysis of language popularity on Github is 
enlightening:


http://www.benfrederickson.com/ranking-programming-languages-by-github-users/


What i found interesting is the comparison between the "newer" 
languages and D ( see the reddit thread ).




While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), 
Go ( Google ).

Even Vala and Crystal are ranked higher then D.


Even vala? You have no idea what the guys at elementary.io are 
doing to get more developers to use Vala and GTK for elementary 
OS (Linux) apps. They are developing an IDE in addition to their 
straight forward Granite toolkit for making app development in 
vala much more easier and productive. They've managed to get over 
70 fully-native apps designed for their OS from independent 
developers since second half of last year, when they launched 
their app center.


I don't know how the D Foundation think or know about growing the 
developer community and tools, but I don't see a good job done in 
that aspect. And...elementary makes less money than D Foundation 
(I think, besides, they don't spend money on their community 
growth... just the obvious "non-technical" stuff).


The committee really need to have a modern approach to this 
community and tools thing.


There have been several complaints about tools, and certain 
important stuff missing in the standard library (HTTP/HTTP2, rpc, 
etc) and no 'official' response or some blog post from them about 
it (whether they even care). Several efforts have been 
made...(the std_* stuff in the dub registry)... still nothing 
much. At least input from committee show they care. I feel like 
its always compiler stuff alone.



Or pay someone good at developer community stuff to take charge. 
I said this some 2 yrs ago (my language about "female" won me 
some insults from some people in the forum, remember? It was 
discussed at the conference with the exception of the idea I was 
trying to communicate). I watched the D 2017 Conference and 
nothing about tools and community growth was discussed (except it 
was not "video-ed"). Unless its not important that much.

Re: std_exception.html#enforce: example does not compile

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 18:34:35 UTC, Jonathan M Davis 
wrote:

The example still does not compile.


That has nothing to do with enforce. std.stdio.readln does not 
take a FILE*. In general, you shouldn't mix core.stdc.stdio and 
std.stdio.


The code is from the official documentation:

- https://dlang.org/phobos/std_exception.html#enforce, and
- https://dlang.org/library/std/exception/enforce.html

Shall I file a bug report?

Re: D generates large assembly for simple function

[Stefan Koch via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:43:50 UTC, Stefan Koch wrote:

On Saturday, 27 January 2018 at 19:42:01 UTC, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976

The actual code is :
 imul edi, edi
 mov eax, edi
 ret


The rest is runtime initialization.
which you can remove using an undocumented -betterC switch.


ah ... -betterC is only for dmd.
try using the gdc compiler instead of ldc.
it does not emit runtime stuff if it's not used.

Re: D generates large assembly for simple function

[Matt via Digitalmars-d-learn]

Godbolt link: https://godbolt.org/g/t5S976

D generates large assembly for simple function

[Matt via Digitalmars-d-learn]

Playing around with Godbolt, D seems to generate an embarassing 
amount of assembly for a simple function (50ish for squaring an 
int vs 4 for C++ and 7 for Rust). Even Go compiles to less 
assembly.


Is there something I'm missing?

Re: D generates large assembly for simple function

[Stefan Koch via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 19:42:01 UTC, Matt wrote:

Godbolt link: https://godbolt.org/g/t5S976

The actual code is :
 imul edi, edi
 mov eax, edi
 ret


The rest is runtime initialization.
which you can remove using an undocumented -betterC switch.

Re: Rewriting a c++ template to D (replacing iterator with ranges "properly")

[aliak via Digitalmars-d-learn]

On Friday, 26 January 2018 at 23:15:41 UTC, Simen Kjærås wrote:


The function is called fill, and assigns a value to every 
element in the range. If a[0] = false compiles, we also want 
a.fill(false) to compile. It's simply testing that, rather than 
caring about the exact type of the elements.


--
  Simen


I see. Yes that makes sense. Thank you.

[Issue 16739] switch ignores case

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from ag0ae...@gmail.com ---
Works for me now with 2.078.0. Pull request to add a test:
https://github.com/dlang/dmd/pull/7793

--

Re: assert and enforce both compiled out with -release

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 18:00:32 UTC, rjframe wrote:
I think I see what you mean; you interpret "use asserts, 
because enforce will be compiled out" to imply that asserts 
wouldn't be compiled out, correct?


Is there any other meaningful interpretation?

Since, in reality, both would be compiled out, it shouldn't 
matter what you use, so the docs shouldn't care. That makes 
sense.


That's precisely my point.

The documentation seems to assume the reader has certain 
expectations of assert and enforce[0], so each function 
expresses a different intention to the programmer; when I see 
`assert()` I expect those checks only in non- release mode; 
when I see `enforce()` I expect those checks regardless of the 
flags that have been set[1]. Placing `enforce` in a contract 
messes with that expectation.


Right.

What language here would make more sense to you? Anything I can 
come up with is either awkward or pretty verbose.


I suggest the deletion of the sentence "Use assert in contracts."

Re: std_exception.html#enforce: example does not compile

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 17:57:54 kdevel via Digitalmars-d-learn wrote:
> On Saturday, 27 January 2018 at 16:10:29 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, January 27, 2018 13:29:00 kdevel via
> >
> > Digitalmars-d-learn wrote:
> >> What's wrong here? And why is the "selective import" of
> >> enforce necessary?
> >
> > Because you named your module enforce. As such, by default,
> > referring to enforce inside of the module refers to the module.
> > Having the selective import overrides that.
>
> Okay. But what about that persisting error message:
>
> zz.d
> ---
> import core.stdc.stdio : fopen;
> import std.stdio : readln, writeln;
> import std.exception; // : enforce;
>
> void main ()
> {
> auto f = enforce(fopen("data.txt", "r"));
> auto line = readln(f);
> enforce(line.length, "Expected a non-empty line.");
> }
> ---
>
> $ dmd zz
> zz.d(8): Error: template std.stdio.readln cannot deduce function
> from argument types !()(shared(_IO_FILE)*), candidates are:
> /.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3921):
> std.stdio.readln(S = string)(dchar terminator = '\x0a') if
> (isSomeString!S)
> /.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3955):
> std.stdio.readln(C)(ref C[] buf, dchar terminator = '\x0a') if
> (isSomeChar!C && is(Unqual!C == C) && !is(C == enum))
> /.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3962):
> std.stdio.readln(C, R)(ref C[] buf, R terminator) if
> (isSomeChar!C && is(Unqual!C == C) && !is(C == enum) &&
> isBidirectionalRange!R && is(typeof(terminator.front ==
> (dchar).init)))
>
> The example still does not compile.

That has nothing to do with enforce. std.stdio.readln does not take a FILE*.
In general, you shouldn't mix core.stdc.stdio and std.stdio.

https://dlang.org/phobos/std_stdio.html#.readln

readln has 3 overloads, all of which read from stdin.

If you want to use readln on a file, then you need to use std.stdio.File and
its member function, readln, not core.stdc.stdio.FILE.

- Jonathan M Davis

[Issue 18318] std.net.curl.download silently ignores non-2xx http statuses

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

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

--- Comment #1 from Martin Nowak  ---
I does throw a CurlException for things like timeouts, connection-failures, or
ssl issues.

--

[Issue 18318] New: std.net.curl.download silently ignores non-2xx http statuses

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

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

  Issue ID: 18318
   Summary: std.net.curl.download silently ignores non-2xx http
statuses
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P5
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
import std.net.curl;

void main()
{
// get("dlang.org/non-existent-foobar"); // throws HTTPStatusException 404
download("dlang.org/non-existent-foobar", "tmp"); // silently writes 404
response, with no way to detect the error
}
CODE

dmd -run bug

--

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Kagamin via Digitalmars-d]

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
I am sorry if this sounds cruel but for now D is on the back 
burner and my next project will probably be in Rust.


If you can cope with Rust ergonomics, I see no reason to not try 
it.
IDEs always worked perfectly for you? My experience is different 
even with paid state of the art flagship IDEs.

Re: assert and enforce both compiled out with -release

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 17:12:25 kdevel via Digitalmars-d-learn wrote:
> Then please explain to me, in which respect the advice to "Use
> assert[s] in contracs" makes sense if the contracts are to be
> compiled out. I don't get it.

The entire point of contracts is to be asserting pre or post conditions. In
some cases, there really isn't much difference between putting the
assertion in the contract from putting it in the body. e.g.

void foo(int i)
in
{
assert(i > 42);
}
do
{
}

and

void foo(int i)
{
assert(i > 42);
}

are pretty much the same, but it can matter. e.g. you can have additional
lines of code in a contract that can't go in a assertion:

void foo(C c, D d, int i)
in
{
auto c = c.foo();
sort(c);
assert(d.bar(i) == c);
}
do
{
}

To do that in the function body, you'd either have to make it a single
expression (which in some cases is easy, and other cases can't be done), or
turn it into a function call where the result of the call gets asserted.
That particular example necessarily isn't a huge motivator for contracts,
but it can be useful.

It's more useful with out contracts, because then you can have have the
assertion in one place rather than with each return statement. e.g.

auto foo(T t)
out(retval)
{
assert(retval.foo() > 19);
}
do
{
if(blah)
return baz();
...
if(t.s == "str")
return doSomething();
...
return t.xyzzy();
}

However, where contracts really matter is with classes. In order for
contracts to work properly with inheritance when a function is overridden,
the in contract of a derived class cannot be more restrictive than that of
the base class. Otherwise, you wouldn't be able to call a function on base
class reference without caring what the actual class of the object was,
because you'd end up with contracts failing based on what the derived class
was. However, while the in contract for a derived function can't be made
stricter, it _can_ be made looser, since that wouldn't make any code fail
based on what the actual object type was, and there's no reason why the
derived class function couldn't work with a greater range of values than the
base class function.

Similarly, a derived function cannot have a looser out contract than the one
in the base class, because that would violate the guarantees that the base
class function makes. However, the derived function _can_ have a stricter
contract, because that doesn't violate the guarantees of the base class, and
there's no reason not to allow the derived class to be stricter about what
it outputs.

As such, with derived functions, the runtime effecively ||s all in
countracts and & all out contracts. In an inheritance chain, _one_ of the
in contracts needs to pass without throwing an AssertError, whereas none of
the out contracts can fail with an AssertError.

So, if you put an assertion in the in contract of a virtual function,
whether it actually has to pass or not depends on what the in contracts of
the other functions in the inheritance chain are, whereas if you put the
assertion in the function body, it always has to pass when that function is
run. However, if that function isn't run (e.g. a derived class function
doesn't call the base class function), then that assertion is never run,
whereas if it's in the in contract, it will be run so long as another in
contract hasn't already passed.

And if you put an assertion in the out contract of a virtual function, it
will always be run, regardless of whether a derived class function calls a
base class function. The only case where it wouldn't be run is if another
out contract had already failed (in which case, the AssertError killed your
program). But if you put the assertion in the function body, it will only be
run if that particular function is run (which may not happen if the derived
class function don't call the base class function).

So, the use of contracts can make a significant difference if you're dealing
with classes, but their benefits are pretty superficial outside of classes.

invariants are far more useful in that they run before and after every
public function call. So, you can assert the state of the object in one
place, and it gets tested whenever the public API is used.

Personally, I almost never use contracts. I rarely use classes, so the
benefits that contracts provide in that case would rarely help me, and in
other cases, I don't think that they provide enough value to bother. For in
contracts, you can just as easily put the assertion in the function unless
you need additional statements to prepare the condition to assert (which I
usually don't), and the contract syntax is verbose enough that I'd prefer to
not use it if I don't have to.

As for out contracts, I don't bother, because I find that it's rare that I
have a function where I can have a condition which is generically testable.
It's very common to be able to test that specific input gives specific
output but not that all output passes a 

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Dgame via Digitalmars-d]

On Saturday, 27 January 2018 at 17:55:06 UTC, H. S. Teoh wrote:

On 1/26/18 5:50 PM, Dgame wrote:

[...]
> My impression so far is that most of the D users love to 
> program in a tiny editor without the features which modern 
> IDE's gives you. That's impressive, but outdated and even a 
> bit silly if the project is bigger.  In any company I've 
> been so far we've used IDE's, because their feature-set and 
> tools take so much work away from you - I don't want to miss 
> them anymore. Nowadays, the majority of programmers who are 
> willing to try new/others programming languages, think so 
> too. I'm somewhat sure that this unneccessary hurdle is one 
> of D's biggest mistakes.

[...]

Not to negate the fact that we *do* need to improve IDE 
support, but the claim that IDEs are "required" for large 
projects is false, and so is the claim that non-IDE editors are 
"tiny". At my day job, I work with a very large codebase 
(50,000+ source files, and yes, I mean 50 *thousand*, not 
hundred), and vim has more than sufficed for the past 10 years. 
And vim does a *lot* more than what some people tend to falsely 
believe that it's "just" another "tiny" text editor on the 
order of NotePad.


This doesn't excuse our poor IDE support, of course, we do need 
to improve our IDE support. But it's tiresome to keep reading 
these unfounded claims that IDE's are somehow inherently 
superior to powerful editors like vim, which is not necessarily 
the case.



T


It's nice that this works for you, but I strongly believe that 
most of the programmers who are willing to try something new are 
younger and I also think that most of them don't use VIM/Emacs on 
a daily basis. It's impressive that you can do it and I'm sure it 
works for you pretty well, but I doubt that younger programmers 
do the same - the hurdle to work with those tools is way to high 
at the start. One of our programmers use VIM too, but on a 
regular basis he has problems like finding/renaming 
files/variables or optimize imports or code formatting. I bet you 
can do that with the right tools and a lot of time as good as an 
IDE can do it, but the IDE can do that out of the box without 
consuming your time. It's like I said - if you mainly used 
VIM/Emacs you think everything is fine and would not try an IDE - 
but that's not what nowadays happens to new programmers. And to 
make D appealing to them, D has to offer good IDE support or it 
will remain as a hobby language with very few exceptions.

[Issue 18317] New: Binop quirks in AST (wrt. typeof(null) and AA) incl. safety hole

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

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

  Issue ID: 18317
   Summary: Binop quirks in AST (wrt. typeof(null) and AA) incl.
safety hole
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ki...@gmx.net

I've just learned that the following is apparently valid code (in the context
of analyzing a reported LDC issue,
https://github.com/ldc-developers/ldc/issues/2537):

void main() @safe
{
typeof(null) nul;
void* ptr;
int[string] aa = [ "one": 123 ];

static assert(!__traits(compiles, ptr + ptr));
auto sum = nul + nul;
auto diff = nul - nul;

static assert(!__traits(compiles, aa + aa));
static assert(!__traits(compiles, aa + ptr));
static assert(!__traits(compiles, ptr + aa));
assert(aa + nul == aa);
assert(nul + aa == aa);

static assert(!__traits(compiles, aa - aa));
static assert(!__traits(compiles, aa - ptr));
static assert(!__traits(compiles, ptr - aa));
assert(aa - nul == aa);
assert(nul - aa == aa);
}

Firstly, these weird binop expressions make it into the AST, so the backend
needs to handle stuff like that.
If `nul + nul` etc. is really supposed to be valid, the front-end could rewrite
the binop as CommaExp `lhs, rhs, typeof(null).init`.
And while `aa + aa` is invalid, `aa + nul` makes it into the AST as `aa +
cast(int[string]) nul`, so that the backend needs to handle additions and
subtractions of associative arrays (semantics?! :D).

Secondly, the last assert leads to a segfault in this @safe code during AA
comparison, as `nul - aa` yields (a pointer to) an invalid AA, so DMD appears
to have chosen pointer subtraction as semantics for AA subtraction.

--

Re: Support of the DB and the interpreter of the MUMPS language which is built in it is added in QtE5

[MGW via Digitalmars-d-announce]

On Wednesday, 17 January 2018 at 08:06:57 UTC, MGW wrote:

Support of the DB and the interpreter of the MUMPS (MiniM)


It is my attempt to study MUMPS bd. All applications are the D + 
QtE5 of my manufacture. Work in Linux, Windows and OSX.


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

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[H. S. Teoh via Digitalmars-d]

> On 1/26/18 5:50 PM, Dgame wrote:
[...]
> > My impression so far is that most of the D users love to program in
> > a tiny editor without the features which modern IDE's gives you.
> > That's impressive, but outdated and even a bit silly if the project
> > is bigger.  In any company I've been so far we've used IDE's,
> > because their feature-set and tools take so much work away from you
> > - I don't want to miss them anymore. Nowadays, the majority of
> > programmers who are willing to try new/others programming languages,
> > think so too. I'm somewhat sure that this unneccessary hurdle is one
> > of D's biggest mistakes.
[...]

Not to negate the fact that we *do* need to improve IDE support, but the
claim that IDEs are "required" for large projects is false, and so is
the claim that non-IDE editors are "tiny". At my day job, I work with a
very large codebase (50,000+ source files, and yes, I mean 50
*thousand*, not hundred), and vim has more than sufficed for the past 10
years. And vim does a *lot* more than what some people tend to falsely
believe that it's "just" another "tiny" text editor on the order of
NotePad.

This doesn't excuse our poor IDE support, of course, we do need to
improve our IDE support. But it's tiresome to keep reading these
unfounded claims that IDE's are somehow inherently superior to powerful
editors like vim, which is not necessarily the case.


T

-- 
Indifference will certainly be the downfall of mankind, but who cares? -- 
Miquel van Smoorenburg

Re: assert and enforce both compiled out with -release

[rjframe via Digitalmars-d-learn]

On Sat, 27 Jan 2018 17:12:25 +, kdevel wrote:

 
> This is not a problem, because this is perfectly legal. The problem is
> the wording of this phrase on the docs:
> 
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks | and invariants), because they will be compiled out when
> compiling with | -release. Use assert in contracts.
> 
> Using assert *IN* contracts in -release mode is equally pointless.

...
 
> | Also, do not use enforce inside of contracts (i.e. inside of in and
> out blocks | and invariants), because they will be compiled out when
> compiling with | -release. Use assert in contracts.
> 
> to me. IMHO this advice is pointless.

...
 
> Then please explain to me, in which respect the advice to "Use assert[s]
> in contracs" makes sense if the contracts are to be compiled out. I
> don't get it.

I think I see what you mean; you interpret "use asserts, because enforce 
will be compiled out" to imply that asserts wouldn't be compiled out, 
correct? Since, in reality, both would be compiled out, it shouldn't 
matter what you use, so the docs shouldn't care. That makes sense.

The documentation seems to assume the reader has certain expectations of 
assert and enforce[0], so each function expresses a different intention to 
the programmer; when I see `assert()` I expect those checks only in non-
release mode; when I see `enforce()` I expect those checks regardless of 
the flags that have been set[1]. Placing `enforce` in a contract messes 
with that expectation.

What language here would make more sense to you? Anything I can come up 
with is either awkward or pretty verbose.

--Ryan


[0]: The correct expectation, but that's not necessarily important when 
it's not explicitly described.
[1]: So you can use enforce to validate user input, but never assert.

Re: std_exception.html#enforce: example does not compile

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 16:10:29 UTC, Jonathan M Davis 
wrote:
On Saturday, January 27, 2018 13:29:00 kdevel via 
Digitalmars-d-learn wrote:
What's wrong here? And why is the "selective import" of 
enforce necessary?


Because you named your module enforce. As such, by default, 
referring to enforce inside of the module refers to the module. 
Having the selective import overrides that.


Okay. But what about that persisting error message:

zz.d
---
import core.stdc.stdio : fopen;
import std.stdio : readln, writeln;
import std.exception; // : enforce;

void main ()
{
   auto f = enforce(fopen("data.txt", "r"));
   auto line = readln(f);
   enforce(line.length, "Expected a non-empty line.");
}
---

$ dmd zz
zz.d(8): Error: template std.stdio.readln cannot deduce function 
from argument types !()(shared(_IO_FILE)*), candidates are:
/.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3921):
std.stdio.readln(S = string)(dchar terminator = '\x0a') if 
(isSomeString!S)
/.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3955):
std.stdio.readln(C)(ref C[] buf, dchar terminator = '\x0a') if 
(isSomeChar!C && is(Unqual!C == C) && !is(C == enum))
/.../dmd2/linux/bin64/../../src/phobos/std/stdio.d(3962):
std.stdio.readln(C, R)(ref C[] buf, R terminator) if 
(isSomeChar!C && is(Unqual!C == C) && !is(C == enum) && 
isBidirectionalRange!R && is(typeof(terminator.front == 
(dchar).init)))


The example still does not compile.

Re: parallelism

[thedeemon via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 11:19:37 UTC, Arun Chandrasekaran 
wrote:

Simplified test case that still errors:


You got really close here. Here's a working version:

enum Operation {
a,
b
}

import std.traits, std.conv, std.stdio;

void main(string[] args) {
auto op = Operation.a;
foreach (_; 0 .. args.length) {
final switch (op) {
foreach(e; EnumMembers!Operation) {
case e:
mixin(e.to!string ~ "();");
break;
}
}
}
}

void a() { writeln("A!"); }
void b() { writeln("B!"); }

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[David Gileadi via Digitalmars-d]

On 1/26/18 5:50 PM, Dgame wrote:

On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote:

On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote:

* Rust: Jetbrain IntelliJ + Rust plugin.
It looks like it has become a official supported plugin by Jetbrain. 
Works perfectly out of the box. Impressive results and issue hinting.


https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ 



Yep, i was right. Its now a official support plugin by Jetbrain.

And no offense but i doubt it has anything to do with Mozilla 
officially backing Rust but more a sign of popularity. Just as how Go 
got its own Editor by Jetbrain.


My impression so far is that most of the D users love to program in a 
tiny editor without the features which modern IDE's gives you. That's 
impressive, but outdated and even a bit silly if the project is bigger. 
In any company I've been so far we've used IDE's, because their 
feature-set and tools take so much work away from you - I don't want to 
miss them anymore. Nowadays, the majority of programmers who are willing 
to try new/others programming languages, think so too. I'm somewhat sure 
that this unneccessary hurdle is one of D's biggest mistakes.


As an IDE junkie I've noticed this correlation in the past too. I wonder 
which direction the causation runs--does D tend to appeal to the no-IDE 
crowd, or do IDE-prefering people abandon D since there hasn't been 
great IDEs support?


Regardless I'm very pleased by the recent trends. The vs-code plugins 
are good and getting better, and DMD as a library should enable simpler 
and more complete language support in any IDE. I believe we're getting 
closer to the point where IDE junkies like me won't feel somewhat 
short-changed, and that's impressive for a community-driven language like D.

Re: Is https://tour.dlang.org under maintenance?

[Seb via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 05:49:00 UTC, ChrisPiker wrote:

On Saturday, 27 January 2018 at 03:08:29 UTC, Seb wrote:

[...]
Well now libevent_pthreads is missing.  Anyway, don't worry 
about it we're (finally) switching over to RedHat 7 soon 
anyway, deployment is underway, that should bring a browser 
that's not an old extended support release.



[...]
I'll build against the native scheduler in the future if I get 
a chance to write any vibe.d code.  Might as well try it out.



[...]

Cool, I'll just use that if needed.

Anyway, you've been so helpful that I've setup a small monthly 
recurring D Foundation donation.


Have a good evening,


Wow thanks a lot!
I hope you don't run into further problems, but if that does 
happen, please feel more than free to post here again!

Re: assert and enforce both compiled out with -release

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 16:19:30 UTC, Jonathan M Davis 
wrote:
On Saturday, January 27, 2018 14:59:50 kdevel via 
Digitalmars-d-learn wrote:

>>> https://github.com/dlang/phobos/blob/master/std/exception.d
>>
>> "Use $(D assert) in contracts." is still in there.
>
> What's wrong with that? What documentation is trying to say 
> is "do not use enforce in contracts; use assert in 
> contracts" and that's exactly the idea.


I can't see a problem which would be solved by following this 
advice. It distracts the reader (me) from gettin his (my) work 
done. If I compile not for release both, enforce and assert, 
are in effect. If I compile for release both, enforce and 
assert, are disabled. So by replacing enforce with assert I 
gain nothing.


No, enforce is _not_ disabled with -release. e.g.


That's not my point.


void foo(int i)
{
enforce(i > 42);
}

void main()
{
foo(0);
}


This is a different case.

will throw an exception even when you compile with -release. 
The problem is that you're using enforce inside a contract 
instead of inside the function's body.


This is not a problem, because this is perfectly legal. The 
problem is the wording of this phrase on the docs:


| Also, do not use enforce inside of contracts (i.e. inside of in 
and out blocks
| and invariants), because they will be compiled out when 
compiling with

| -release. Use assert in contracts.

Using assert *IN* contracts in -release mode is equally pointless.

Contracts are specifically for asserting pre and post 
conditions. It is expected that they only be used for 
assertions or for code which is going to be run in preparation 
for running an assertion. They are _not_ for code which is 
intended to be part of the final program, and they are compiled 
out with -release, just like assertions are compiled out 
elsewhere in the code. As such, any code in a contract - be it 
an assertion, a call to enforce, or any arbitarily complex 
piece of code - will not be in the final program.


Then please explain the meaning of the sentence

 Use assert in contracts.

in this context:

| Also, do not use enforce inside of contracts (i.e. inside of in 
and out blocks
| and invariants), because they will be compiled out when 
compiling with

| -release. Use assert in contracts.

to me. IMHO this advice is pointless.

Anything that you want in your final program should not be in a 
contract. If you want to use exceptions - be it with enforce or 
with an if statement and explicitly throwing - then don't put 
them in any contracts. They _will_ get compiled out. As such, 
it makes no sense to use enforce in a contract. It should go in 
the function body.


Then please explain to me, in which respect the advice to "Use 
assert[s] in contracs" makes sense if the contracts are to be 
compiled out. I don't get it.

Re: Class member function calls inside ctor and dtor

[Jonathan M Davis via Digitalmars-d]

On Saturday, January 27, 2018 16:18:26 Thomas Mader via Digitalmars-d wrote:
> On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:
> > I'm working on devirtualization and for that it's crucial to
> > know some spec details (or define them in the spec if they
> > aren't yet).
> >
> > Currently, calling non-final member functions in the destructor
> > is allowed and these indirect calls are to the possibly
> > overridden functions of derived classes. That is, inside a base
> > class constructor, the object's type is its final type (so
> > possibly of a derived class). This is the same in the
> > destructor. Thus, the object's dynamic type does not change
> > during its lifetime.
>
> Can't answer your question but have a little question.
> How is the behavior different to the situation in C++? They argue
> that it's not good to call virtual methods in Con-/Destructors in
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-ctor-virtu
> al
>
> So I guess it should better be not used in D as well?

D solved that problem. In C++, when you're in the base class constructor,
the object doesn't have its derived type yet. It's still just the base
class. Each class level gets add as it's constructed (the same in reverse
with the destructor). You don't have a full object until all constructors
have been run, and once you start running destructors, you don't have a full
class anymore either.

In D, on the other hand, the object is initialized with its init value
_before_ any constructors are run. So, it's a full object with a full type,
and everything virtual is going to get the type right.

- Jonathan M Davis

[Issue 18316] New: std.net.curl.SMTP.mailTo fails to compile

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

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

  Issue ID: 18316
   Summary: std.net.curl.SMTP.mailTo fails to compile
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: zan77...@nifty.com

Following code doesn't work:

---
void main()
{
// from example of https://dlang.org/phobos/std_net_curl.html#.SMTP
import std.net.curl;

// Send an email with SMTPS
auto smtp = SMTP("smtps://smtp.gmail.com");
smtp.setAuthentication("from.a...@gmail.com", "password");
smtp.mailTo = [""]; // <-- NG
smtp.mailFrom = "";
smtp.message = "Example Message";
smtp.perform();
}
--
$ dmd -run main
P:\app\dmd\bin64\..\import\std\net\curl.d(4055): Error: no property tempCString
for type const(char)[]
main.d(8): Error: template instance std.net.curl.SMTP.mailTo!() error
instantiat
ing
--

This is probably caused by this commit:
https://github.com/dlang/phobos/commit/ca0777a1a7a2ae9cc6f287a6fe8482e61047afb2
mailTo seems to be left out of these changes.

--

Re: Class member function calls inside ctor and dtor

[Johan Engelen via Digitalmars-d]

On Saturday, 27 January 2018 at 16:18:26 UTC, Thomas Mader wrote:


Can't answer your question but have a little question.
How is the behavior different to the situation in C++?


In C++, the dynamic type of an object changes during construction 
and destruction (e.g. base class ctor calls base class 
implementation of virtual functions).
Because of that, it may be confusing to call virtual functions in 
the ctor/dtor, and people advice against it. In D, the situation 
is much more clear (imo).


- Johan

Re: functions allowed to overload on const int vs int vs immutable int? + spec is not accurate

[Marco Leise via Digitalmars-d]

Am Fri, 26 Jan 2018 19:45:54 +
schrieb timotheecour :

> this compiles, but equivalent in C++ (const int vs int) would 
> give a
> compile error (error: redefinition of 'fun'); what's the 
> rationale for
> allowing these overloads?
> 
> ```
> void fun(int src){ writeln2(); }
> void fun(immutable int src){ writeln2(); }
> void fun(const int src){ writeln2(); }

There is also `inout` and `shared`. Granted, for basic types
it makes no difference, but once references are involved you
benefit from keeping the qualifier. A const or mutable string
must be assumed to change after the function returns.
Immutable strings on the other hand can be copied by reference.
Immutable stuff is also implicitly shared, so can be used by
multiple threads without synchronization. Optimizations for
mutable versions only are also possible, like in-place
editing. 

If your implementation is the same for immutable and mutable
qualifiers, just provide the const version, but keep in mind
that the type qualifiers are lost then. Any functions you call
further down will also use their "const" implementation.

Doing this as an overload of course helps with generic
programming and maintenance. You can migrate from "const" only
to providing multiple implementations without inventing new
names or breaking code.

It may also have to do with how C++'s const is not much more
than a static check, while D's immutable is both transitive
and supposed to give strong guarantees that the object never
changes. That assumption is somewhat tied to the idea that
immutable objects are either in read-only sections of the
executable or that the garbage collector will keep them alive
until all references are gone.

-- 
Marco

Re: assert and enforce both compiled out with -release

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 14:59:50 kdevel via Digitalmars-d-learn wrote:
> On Saturday, 27 January 2018 at 14:51:23 UTC, Ali Çehreli wrote:
> > On 01/27/2018 06:36 AM, kdevel wrote:
> >> On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli
> >>
> >> wrote:
> >>> > But assert is also ignored in release mode:
> >>> The documentation is not clear. "they will be compiled out"
> >>> means "contracts are compiled out". So, an enforce() would
> >>> disappear if it's inside such a block, which should not be
> >>> what the programmer wants for an enforce().
> >>
> >> The documentation was clear as glass (but wrong): "Use assert
> >> in contracts."
> >>
> >>> Fixed it through the "Improve this page" link on that Phobos
> >>> page:
> >>>
> >>>   https://github.com/dlang/phobos/blob/master/std/exception.d
> >>
> >> "Use $(D assert) in contracts." is still in there.
> >
> > What's wrong with that? What documentation is trying to say is
> > "do not use enforce in contracts; use assert in contracts" and
> > that's exactly the idea.
>
> I can't see a problem which would be solved by following this
> advice. It distracts the reader (me) from gettin his (my) work
> done. If I compile not for release both, enforce and assert, are
> in effect. If I compile for release both, enforce and assert, are
> disabled. So by replacing enforce with assert I gain nothing.

No, enforce is _not_ disabled with -release. e.g.

void foo(int i)
{
enforce(i > 42);
}

void main()
{
foo(0);
}

will throw an exception even when you compile with -release. The problem is
that you're using enforce inside a contract instead of inside the function's
body.

Contracts are specifically for asserting pre and post conditions. It is
expected that they only be used for assertions or for code which is going to
be run in preparation for running an assertion. They are _not_ for code
which is intended to be part of the final program, and they are compiled out
with -release, just like assertions are compiled out elsewhere in the code.
As such, any code in a contract - be it an assertion, a call to enforce, or
any arbitarily complex piece of code - will not be in the final program.

Anything that you want in your final program should not be in a contract. If
you want to use exceptions - be it with enforce or with an if statement and
explicitly throwing - then don't put them in any contracts. They _will_ get
compiled out. As such, it makes no sense to use enforce in a contract. It
should go in the function body.

- Jonathan M Davis

Re: Class member function calls inside ctor and dtor

[Thomas Mader via Digitalmars-d]

On Saturday, 27 January 2018 at 14:48:08 UTC, Johan Engelen wrote:
I'm working on devirtualization and for that it's crucial to 
know some spec details (or define them in the spec if they 
aren't yet).


Currently, calling non-final member functions in the destructor 
is allowed and these indirect calls are to the possibly 
overridden functions of derived classes. That is, inside a base 
class constructor, the object's type is its final type (so 
possibly of a derived class). This is the same in the 
destructor. Thus, the object's dynamic type does not change 
during its lifetime.


Can't answer your question but have a little question.
How is the behavior different to the situation in C++? They argue 
that it's not good to call virtual methods in Con-/Destructors in 
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-ctor-virtual


So I guess it should better be not used in D as well?

Re: std_exception.html#enforce: example does not compile

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 13:29:00 kdevel via Digitalmars-d-learn wrote:
> What's wrong here? And why is the "selective import" of enforce
> necessary?

Because you named your module enforce. As such, by default, referring to
enforce inside of the module refers to the module. Having the selective
import overrides that.

It's generally not a good idea to name your module the same name something
that you would refer to inside the module. It's usually not an issue in real
programs, because in that case, aside from maybe the module with main,
modules aren't at the top-level, but if you're doing something like naming
your test program after a function that you're using in it, you're going to
have problems.

- Jonathan M Davis

Re: Strange compiler error. Whose bug is that?

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, January 27, 2018 09:35:05 Oleksii Skidan via Digitalmars-d-
learn wrote:
> On Saturday, 27 January 2018 at 08:18:07 UTC, thedeemon wrote:
> > On Friday, 26 January 2018 at 21:17:14 UTC, Oleksii Skidan
> >
> > wrote:
> >> struct Game {
> >>
> >> Triangle player = new Triangle;
> >
> > When you initialize a struct member like this, compiler tries
> > to calculate the initial value and remember it as data, so each
> > time such struct is constructed the data is just copied. Which
> > means this data must be computable at compile time, however
> > your Triangle constructor is using pointers to some values,
> > these pointers will only be known at run time. This means you
> > need to construct Triangles at run time, in Game constructor,
> > not at compile time in this initialization syntax.
>
> Got it. But are reference-types "computable" at compile time at
> all? Shouldn't they be relying on D runtime?
>
> To my understanding Triangle instantiation happens when Game
> constructor is called. I assume that D runtime has been
> initialized already, and thus there should be a valid GC and it
> should be fine to instantiate a reference-type.
>
> As well, if I'm wrong about Game constructor, then compiler
> generated errors are wrong and misleading. The compiler should be
> swearing at `Triangle player = new Triangle;`, or not?

I don't think that "computable" is really the best way to look at this. It's
more an isssue of the value being carried over from compile time to runtime.
But I'll try to explain it. You're clearly assuming that some stuff is
happening at runtime that happens at compile time.

Module-level variables, static variables, and member varibales which are
directly initialized must all have their values known at compile time. If
you have something like

static int i = foo();

or

struct S
{
int i = foo();
}

then the compiler must know the value of i at compile time. As such, foo
must be run at compile time so that the resulting value can be known and
stored in the program. In the case of a member variable of a struct, that's
in the init value of the struct (it's the same for classes except that you
don't have access to it, since with classes, you always operate on
references, never the class itself, and the class reference's init value is
null; the underlying object still has an init value though).

For module-level variables and static variables, the runtime may need to do
some stuff on program or thread start-up to fill in the values, but they're
all known at compile time. For member variables, the object is initialized
to the type's init value when the object is created, and then if a
constructor is used, it is run. In the case of

S s;

no constructor is run (s is just filled in with the init value), whereas
with something like

auto s = S("hello");

or

auto c = new MyClass(42);

the object is filled in with the init value and then a constructor is run.
Either way, if you have

struct S
{
int i = foo();
}

foo was run at compile time and not rerun at runtime. Its result is part of
S.init.

If a value is set in the constructor, e.g.

struct S
{
int i = foo();
string s;

this(string s)
{
this.s = s;
}
}

then that's done at runtime, but all of the direct initializions are done at
compile time when determining the value of S.init.

Given how all of this works, it's actually king of crazy that reference
types work at all. Consider,

struct S
{
auto arr = [1, 2, 3, 4];
}

arr must be known at compile time, and yet are is just a pointer and a
length pointing to heap memory. Heap memory isn't part of the executable.
It's part of a specific run of the program. So, somehow, the value of the
memory that arr refers to needs to be calculated at compile time and then
reconstructed at runtime. The runtime has to recreate it in memory from the
value that was known at compile time. It's not going to rerun any functions,
so if you have

struct S
{
int[] arr = foo();
}

foo still has to have been run at compile time. The resulting value will
need to have been stored somehow so that S.init can contain a normal dynamic
array that points to heap memory at runtime.

For the compiler to work like this with dynamic arrays, it had to have had
work done specifically for dynamic arrays so that the runtime would know how
to reconstruct them. That's not something that can easily be done for
arbitrary types - and it hasn't even been done for some of the simple stuff,
though what has been done has increased over time. e.g.

struct S
{
int* i = new int(42);
}

will not compile. But for arbitrarily complex user-defined types, it gets
far more complex. So, if you have something like

struct S
{
auto myClass = new MyClass(42);
}

the compiler does not transfer the value of the class reference at compile
time to runtime. In years past, I would have simply explained the compiler
and runtime don't understand how to reconstruct a class like that (heck, the

[Issue 18315] wrong code for `i > 0`

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

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

Stefan  changed:

   What|Removed |Added

 CC||kde...@vogtner.de

--

Re: enforce (i > 0) for i = int.min does not throw

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 14:49:52 UTC, Ali Çehreli wrote:
But enforce is a red herring there. This prints true with 2.078 
as well:


import std.stdio;

void main ()
{
int i = int.min;
writeln(i > 0);// prints 'true' with 2.078
}


test.d
---
import std.stdio;
void main ()
{
   int i = int.min;
   auto b = i > 0;
   b.writeln;
   auto c = int.min > 0;
   c.writeln;
}
---
$ dmd test.d
$ ./test
true
false

Re: assert and enforce both compiled out with -release

[kdevel via Digitalmars-d-learn]

On Saturday, 27 January 2018 at 14:51:23 UTC, Ali Çehreli wrote:

On 01/27/2018 06:36 AM, kdevel wrote:
On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli 
wrote:

> But assert is also ignored in release mode:

The documentation is not clear. "they will be compiled out" 
means "contracts are compiled out". So, an enforce() would 
disappear if it's inside such a block, which should not be 
what the programmer wants for an enforce().


The documentation was clear as glass (but wrong): "Use assert 
in contracts."


Fixed it through the "Improve this page" link on that Phobos 
page:


  https://github.com/dlang/phobos/blob/master/std/exception.d


"Use $(D assert) in contracts." is still in there.


What's wrong with that? What documentation is trying to say is 
"do not use enforce in contracts; use assert in contracts" and 
that's exactly the idea.


I can't see a problem which would be solved by following this 
advice. It distracts the reader (me) from gettin his (my) work 
done. If I compile not for release both, enforce and assert, are 
in effect. If I compile for release both, enforce and assert, are 
disabled. So by replacing enforce with assert I gain nothing.

[Issue 18315] wrong code for `i > 0`

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

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All

--

[Issue 18315] wrong code for `i > 0`

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #2 from Steven Schveighoffer  ---
Wow, this is really old. Tested all the way back to 2.040, still fails.

--

[Issue 18315] wrong code for `i > 0`

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 OS|Linux   |All

--- Comment #3 from Steven Schveighoffer  ---
Also fails on MacosX.

--

Re: assert and enforce both compiled out with -release

[Ali Çehreli via Digitalmars-d-learn]

On 01/27/2018 06:36 AM, kdevel wrote:

On Saturday, 27 January 2018 at 14:31:13 UTC, Ali Çehreli wrote:

> But assert is also ignored in release mode:

The documentation is not clear. "they will be compiled out" means 
"contracts are compiled out". So, an enforce() would disappear if it's 
inside such a block, which should not be what the programmer wants for 
an enforce().


The documentation was clear as glass (but wrong): "Use assert in 
contracts."



Fixed it through the "Improve this page" link on that Phobos page:

  https://github.com/dlang/phobos/blob/master/std/exception.d


"Use $(D assert) in contracts." is still in there.


What's wrong with that? What documentation is trying to say is "do not 
use enforce in contracts; use assert in contracts" and that's exactly 
the idea.


Ali

Re: enforce (i > 0) for i = int.min does not throw

[ag0aep6g via Digitalmars-d-learn]

On 01/27/2018 03:13 PM, kdevel wrote:

I would expect this code

enforce3.d
---
import std.exception;

void main ()
{
    int i = int.min;
    enforce (i > 0);
}
---

to throw an "Enforcement failed" exception, but it doesn't:

$ dmd enforce3.d
$ ./enforce3
[nothing]




Wow, that looks really bad.

Apparently, dmd implements `i < 0` as a `i >> 31`. I.e., it shifts the 
bits to the right so far that only the sign bit is left. This is ok.


But it implements `i > 0` as `(-i) >> 31`. That would be correct if 
negation would always flip the sign bit. But it doesn't for `int.min`. 
`-int.min` is `int.min` again.


So dmd emits wrong code for `i > 0`. O_O

I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=18315