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

[Dmitry Olshansky via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 23:29:28 UTC, Walter Bright wrote:

On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:

Safety - not so much.


I remember back in the olden dayz when Microsoft was pushing 
ActiveX controls hard. ActiveX controls were blobs of code 
automatically downloaded from the internet that were embedded 
in your spreadsheet, word document, etc.


What could possibly go wrong? :-)


I remember it... I even used some :)
And it was efficient!

But look at it today - many websites are basically a huge program 
running in a sandbox. And with more APIs they don’t need a 
particular page open to run in background and many other 
limitations are lifted.


Still don’t understand why code signing became required on 
desktop, but not in the web.

[Issue 15206] ICE on optimized build, tym = x1d Internal error: backend\cgxmm.c 547

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

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

--- Comment #6 from Walter Bright  ---
This is frustrating. I cannot reproduce this issue.

--

[Issue 18691] assigning a std.regex.Captures with 3 or more groups causes double free

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

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

--- Comment #2 from Martin Dorey  ---
How frustrating.  I can reproduce it on every one of the three machines I've
tried.  The output I raised the issue with was from today's master built on
Debian Jessie.  I found the problem originally on stock 2.079-0 from d-apt on
Debian Stretch... like the one below.  I was hoping for more symbolic debugging
but the -g doesn't seem to affect it for me.

mad@shuttle:~/tmp/D134366$ dmd --version
DMD64 D Compiler v2.079.0
Copyright (C) 1999-2018 by The D Language Foundation, All Rights Reserved
written by Walter Bright
mad@shuttle:~/tmp/D134366$ dmd -g utilimal.d && ./utilimal
*** Error in `./utilimal': double free or corruption (fasttop):
0x563fea6ca140 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f8c10084bcb]
/lib/x86_64-linux-gnu/libc.so.6(+0x76f96)[0x7f8c1008af96]
/lib/x86_64-linux-gnu/libc.so.6(+0x777de)[0x7f8c1008b7de]
./utilimal(_D3std5regex__T8CapturesTAyaZQo6__dtorMFNbNiNeZv+0x3b)[0x563fe94fda3f]
./utilimal(_Dmain+0xfd)[0x563fe94c6ea9]
./utilimal(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x28)[0x563fe9502b88]
./utilimal(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv+0x20)[0x563fe9502a18]
./utilimal(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv+0x8b)[0x563fe9502af7]
./utilimal(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv+0x20)[0x563fe9502a18]
./utilimal(_d_run_main+0x1cf)[0x563fe9502983]
./utilimal(main+0x22)[0x563fe94febd6]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f8c100342b1]
./utilimal(_start+0x2a)[0x563fe94c6c2a]
=== Memory map: 
563fe9426000-563fe9569000 r-xp  08:07 76285143  
/u2/home/mad/tmp/D134366/utilimal
563fe9769000-563fe976a000 r--p 00143000 08:07 76285143  
/u2/home/mad/tmp/D134366/utilimal
563fe976a000-563fe979f000 rw-p 00144000 08:07 76285143  
/u2/home/mad/tmp/D134366/utilimal
563fea6ca000-563fea6eb000 rw-p  00:00 0  [heap]
7f8c0c00-7f8c0c021000 rw-p  00:00 0 
7f8c0c021000-7f8c1000 ---p  00:00 0 
7f8c10014000-7f8c101a9000 r-xp  08:01 1859659   
/lib/x86_64-linux-gnu/libc-2.24.so
7f8c101a9000-7f8c103a9000 ---p 00195000 08:01 1859659   
/lib/x86_64-linux-gnu/libc-2.24.so
7f8c103a9000-7f8c103ad000 r--p 00195000 08:01 1859659   
/lib/x86_64-linux-gnu/libc-2.24.so
7f8c103ad000-7f8c103af000 rw-p 00199000 08:01 1859659   
/lib/x86_64-linux-gnu/libc-2.24.so
7f8c103af000-7f8c103b3000 rw-p  00:00 0 
7f8c103b3000-7f8c103c9000 r-xp  08:01 1859854   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8c103c9000-7f8c105c8000 ---p 00016000 08:01 1859854   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8c105c8000-7f8c105c9000 r--p 00015000 08:01 1859854   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8c105c9000-7f8c105ca000 rw-p 00016000 08:01 1859854   
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f8c105ca000-7f8c105cd000 r-xp  08:01 1859704   
/lib/x86_64-linux-gnu/libdl-2.24.so
7f8c105cd000-7f8c107cc000 ---p 3000 08:01 1859704   
/lib/x86_64-linux-gnu/libdl-2.24.so
7f8c107cc000-7f8c107cd000 r--p 2000 08:01 1859704   
/lib/x86_64-linux-gnu/libdl-2.24.so
7f8c107cd000-7f8c107ce000 rw-p 3000 08:01 1859704   
/lib/x86_64-linux-gnu/libdl-2.24.so
7f8c107ce000-7f8c107d5000 r-xp  08:01 1859828   
/lib/x86_64-linux-gnu/librt-2.24.so
7f8c107d5000-7f8c109d4000 ---p 7000 08:01 1859828   
/lib/x86_64-linux-gnu/librt-2.24.so
7f8c109d4000-7f8c109d5000 r--p 6000 08:01 1859828   
/lib/x86_64-linux-gnu/librt-2.24.so
7f8c109d5000-7f8c109d6000 rw-p 7000 08:01 1859828   
/lib/x86_64-linux-gnu/librt-2.24.so
7f8c109d6000-7f8c10ad9000 r-xp  08:01 1859707   
/lib/x86_64-linux-gnu/libm-2.24.so
7f8c10ad9000-7f8c10cd8000 ---p 00103000 08:01 1859707   
/lib/x86_64-linux-gnu/libm-2.24.so
7f8c10cd8000-7f8c10cd9000 r--p 00102000 08:01 1859707   
/lib/x86_64-linux-gnu/libm-2.24.so
7f8c10cd9000-7f8c10cda000 rw-p 00103000 08:01 1859707   
/lib/x86_64-linux-gnu/libm-2.24.so
7f8c10cda000-7f8c10cf2000 r-xp  08:01 1859816   
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f8c10cf2000-7f8c10ef1000 ---p 00018000 08:01 1859816   
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f8c10ef1000-7f8c10ef2000 r--p 00017000 08:01 1859816   
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f8c10ef2000-7f8c10ef3000 rw-p 00018000 08:01 1859816   
/lib/x86_64-linux-gnu/libpthread-2.24.so
7f8c10ef3000-7f8c10ef7000 rw-p  00:00 0 
7f8c10ef7000-7f8c10f1a000 r-xp  08:01 1859630   

Re: D RAII with postblit disabled

[Adam D. Ruppe via Digitalmars-d-learn]

On Thursday, 29 March 2018 at 04:12:38 UTC, Norm wrote:
Is there a way to do this in D, or does it require special 
"create" functions for every struct that has a RAII-like struct 
as a member?


You'll have to do it all the way up (unless you can use a 
constructor with an argument and call that instead)

Re: D RAII with postblit disabled

[Norm via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 02:43:15 UTC, Adam D. Ruppe wrote:

On Tuesday, 27 March 2018 at 02:35:23 UTC, Norm wrote:

What's the best way to do this in D?


I'd also add `@disable this();` and then a `static O make() { 
return O(theAllocator.make!int(99)); }`


than you construct it with that static make function.


OK, that got me over the first hurdle but I still cannot use RAII 
with struct member vars. E.g.


---
struct Resource {
  this() {allocate_something();}
  ~this() {release_something();}
}

struct S {
  Resource resource;
}

---

Is there a way to do this in D, or does it require special 
"create" functions for every struct that has a RAII-like struct 
as a member?



Thanks,
Norm

Re: D vs nim

[Arun Chandrasekaran via Digitalmars-d]

On Tuesday, 27 March 2018 at 23:23:10 UTC, Timothee Cour wrote:

that comment was regarding -betterC
RAII (with structs) has been available in D for a while, eg:

```d
struct A{
  ~this(){...}
}

void fun(){
  A a; // when a goes out of scope, will call dtor 
deterministically

}
```


On Tue, Mar 27, 2018 at 4:15 PM, Ali via Digitalmars-d 
 wrote:

On Tuesday, 27 March 2018 at 01:19:44 UTC, timotheecour wrote:

[...]



How is RAII available in D? I did a quick search on this forum 
but didnt exactly find what I want


I found a comment for Walter (saying it was recently added 
https://forum.dlang.org/post/p1pa01$kc8$1...@digitalmars.com)


What was the added feature that now enables RAII in D


This is deterministic destruction and not RAII. Resource is never 
*acquired* here. Lack of default constructors for struct in D 
makes it impossible to achieve the RAII as in C++.

[Issue 17918] [Reg 2.072] ICE with unknown symbol in base class

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

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

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

   What|Removed |Added

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

--

[Issue 17918] [Reg 2.072] ICE with unknown symbol in base class

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

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

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

https://github.com/dlang/dmd/commit/352b70901d19ac173899e9d7d21aee60d43ed9be
Fix issue 17918 - Stop if the late semantic pass fails

No matter what the outcome of finishVtbl was the old code kept building
the rest of the class. If the late semantic pass over the
FunctionDeclaration fails we should abort the codegen phase instead of
going on.

https://github.com/dlang/dmd/commit/d17cde4f4d16274960ab0a55fa1dc4d2b1e0625f
Merge pull request #8096 from LemonBoy/b17918

Fix issue 17918 - Stop if the late semantic pass fails
merged-on-behalf-of: Walter Bright 

--

[Issue 18476] -run should not only take the next argument

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

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

--- Comment #1 from Seb  ---
See also: https://github.com/dlang/dmd/pull/7927

--

[Issue 18477] -run isn't DRY and leads to unexpected errors

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

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

--- Comment #2 from Seb  ---
See also: https://github.com/dlang/dmd/pull/7927

--

[Issue 18260] ICE on template this parameter and alias this

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #5 from Seb  ---
> but the first example still causes DMD to freeze.

Here's a stack trace - it looks like compare_overload runs into an endless
recursion:

---
0x559cf3de in rt.util.array._enforceNoOverlap(const(char[]), ulong,
ulong, const(ulong)) ()
#0  0x559cf3de in rt.util.array._enforceNoOverlap(const(char[]), ulong,
ulong, const(ulong)) ()
#1  0x559c98ef in _d_arraycopy ()
#2  0x559c3166 in _d_newclass (ci=0x55ab4860 ) at dmd/root/rmem.d:210
#3  0x557f2adc in
TemplateDeclaration::deduceFunctionTemplateMatch(TemplateInstance*, Scope*,
FuncDeclaration*&, Type*, Array*) (this=0x77e9f7d0,
ti=0x7510e330, sc=0x769f8f70, fd=@0x7f7ff960: 0x77e9f470,
tthis=0x77e9fb20, fargs=0x0) at dmd/dtemplate.d:1118
#4  0x557f7048 in int
dmd.dtemplate.functionResolve(dmd.declaration.Match*, dmd.dsymbol.Dsymbol,
dmd.globals.Loc, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type,
dmd.root.array.Array!(dmd.expression.Expression).Array*,
const(char)**).applyTemplate(dmd.dtemplate.TemplateDeclaration)
(this=0x7f7ffb50, td=0x77e9f7d0) at dmd/dtemplate.d:2690
#5  0x557f7500 in int
dmd.dtemplate.functionResolve(dmd.declaration.Match*, dmd.dsymbol.Dsymbol,
dmd.globals.Loc, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type,
dmd.root.array.Array!(dmd.expression.Expression).Array*,
const(char)**).__lambda11(dmd.dsymbol.Dsymbol) (this=0x7f7ffb50,
s=0x77e9f7d0) at dmd/dtemplate.d:2797
#6  0x5583bc34 in int dmd.func.overloadApply(dmd.dsymbol.Dsymbol, int
delegate(dmd.dsymbol.Dsymbol), dmd.dscope.Scope*) (sc=0x769f8f70, dg=...,
fstart=0x77e9f7d0) at dmd/func.d:2414
#7  0x557f5e21 in void
dmd.dtemplate.functionResolve(dmd.declaration.Match*, dmd.dsymbol.Dsymbol,
dmd.globals.Loc, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type,
dmd.root.array.Array!(dmd.expression.Expression).Array*, const(char)**)
(pMessage=0x7f7ffbb0, fargs=0x0, tthis=0x77e9fb20, tiargs=0x0,
sc=0x769f8f70, loc=..., dstart=0x77e9f7d0, m=0x7f7ffb90) at
dmd/dtemplate.d:2799
#8  0x5583bfff in resolveFuncCall(Loc const&, Scope*, Dsymbol*,
Array*, Type*, Array*, int) (loc=...,
sc=0x769f8f70, s=0x77e9f7d0, tiargs=0x0, tthis=0x77e9fb20,
fargs=0x0, flags=0) at dmd/func.d:2575
#9  0x55821b86 in ExpressionSemanticVisitor::visit(CallExp*)
(this=0x7f800788, exp=0x7510e2e0) at dmd/expressionsem.d:3142
#10 0x558144ae in CallExp::accept(Visitor*) (this=0x7510e2e0,
v=0x7f800788) at dmd/expression.d:5607
#11 0x5583461f in expressionSemantic(Expression*, Scope*)
(e=0x7510e2e0, sc=0x769f8f70) at dmd/expressionsem.d:9367
#12 0x55819509 in dmd.expression.Expression
dmd.expressionsem.resolvePropertiesX(dmd.dscope.Scope*,
dmd.expression.Expression, dmd.expression.Expression) (e2=0x0,
e1=0x7510d7d0, sc=0x769f8f70) at dmd/expressionsem.d:253
#13 0x558198a7 in resolveProperties(Scope*, Expression*)
(sc=0x769f8f70, e=0x7510d7d0) at dmd/expressionsem.d:329
#14 0x5583457d in dmd.expression.Expression
dmd.expressionsem.binSemanticProp(dmd.expression.BinExp, dmd.dscope.Scope*)
(sc=0x769f8f70, e=0x55f54b40) at dmd/expressionsem.d:9352
#15 0x5583320e in ExpressionSemanticVisitor::visit(EqualExp*)
(this=0x7f800d18, exp=0x55f54b40) at dmd/expressionsem.d:8900
#16 0x55816dd2 in EqualExp::accept(Visitor*) (this=0x55f54b40,
v=0x7f800d18) at dmd/expression.d:6981
#17 0x5583461f in expressionSemantic(Expression*, Scope*)
(e=0x55f54b40, sc=0x769f8f70) at dmd/expressionsem.d:9367
#18 0x5583440c in dmd.expression.Expression
dmd.expressionsem.trySemantic(dmd.expression.Expression, dmd.dscope.Scope*)
(sc=0x769f8f70, exp=0x55f54b40) at dmd/expressionsem.d:9294
#19 0x5588bd8c in dmd.expression.Expression
dmd.opover.compare_overload(dmd.expression.BinExp, dmd.dscope.Scope*,
dmd.identifier.Identifier) (id=0x77e9d3c0, sc=0x769f8f70,
e=0x55f547d0) at dmd/opover.d:1666
#20 0x5588a171 in op_overload::OpOverload::visit(EqualExp*)
(this=0x7f8012a0, e=0x55f547d0) at dmd/opover.d:1175
#21 0x55816dd2 in EqualExp::accept(Visitor*) (this=0x55f547d0,
v=0x7f8012a0) at dmd/expression.d:6981
#22 0x5588797d in op_overload(Expression*, Scope*) (e=0x55f547d0,
sc=0x769f8f70) at dmd/opover.d:1536
#23 0x5580d551 in Expression::op_overload(Scope*) 

[Issue 18581] Segmentation fault with dmd -X if static foreach inside template

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

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

Seb  changed:

   What|Removed |Added

   Keywords||ice
 CC||greensunn...@gmail.com
   Severity|normal  |critical

--

[Issue 18481] demangling error in stacktrace

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

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

--- Comment #3 from Seb  ---
Oh and exploring a bit when I look at the ICE in
https://issues.dlang.org/show_bug.cgi?id=18136, I get the following stack trace
with only partial demangling:

```
core.exception.AssertError@dmd/statement.d(425): Assertion failure

??:? _d_assertp [0xdc37fbf5]
??:? dmd.statement.ErrorStatement dmd.statement.ErrorStatement.__ctor()
[0xdc25ec05]
??:? _ZN16Semantic3Visitor5visitEP15FuncDeclaration [0xdc291e83]
??:? _ZN16ParseTimeVisitorI10ASTCodegenE5visitEP22FuncLiteralDeclaration
[0xdc275ef1]
??:? _ZN22FuncLiteralDeclaration6acceptEP7Visitor [0xdc1f5739]
??:? _Z9semantic3P7DsymbolP5Scope [0xdc29062c]
??:? _ZN25ExpressionSemanticVisitor5visitEP7FuncExp [0xdc1d80be]
??:? _ZN7FuncExp6acceptEP7Visitor [0xdc1ca119]
??:? _Z18expressionSemanticP10ExpressionP5Scope [0xdc1ec61e]
??:? _ZN14ResolveVisitor5visitEP10TypeTypeof [0xdc26a43a]
...
??:? int dmd.dtemplate.functionResolve(dmd.declaration.Match*,
dmd.dsymbol.Dsymbol, dmd.globals.Loc, dmd.dscope.Scope*,
dmd.root.array.Array!(dmd.root.rootobject.RootObject).Array*, dmd.mtype.Type,
dmd.root.array.Array!(dmd.expression.Expression).Array*,
const(char)**).applyTemplate(dmd.dtemplate.TemplateDeclaration) [0xdc1af047]
??:?
_Z15resolveFuncCallRK3LocP5ScopeP7DsymbolP5ArrayIP10RootObjectEP4TypePS6_IP10ExpressionEi
[0xdc1f3ffe]
??:? _ZN25ExpressionSemanticVisitor5visitEP7CallExp [0xdc1dad73]
```

--

[Issue 18481] demangling error in stacktrace

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
Well it seems to be an issue with the mangling in gdb (maybe the new
backreferencing mangling isn't supported yet?). I would guess that it's a
similar issue on OSX with LLDB?

How to reproduce:

1) pick a random ICE
2) compile dmd with ENABLE_DEBUG=1
3) get the stacktrace


```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x55806135 in
_D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv
(er=0x7fffb730, e=0x0) at dmd/escape.d:1293
1293e.accept(v);
#0  0x55806135 in
_D3dmd6escape13escapeByValueFCQBc10expression10ExpressionPSQCfQCe15EscapeByResultsZv
(er=0x7fffb730, e=0x0) at dmd/escape.d:1293
#1  0x558052b9 in
_D3dmd6escape14checkNewEscapeFPSQBe6dscope5ScopeCQBv10expression10ExpressionbZb
(gag=false, e=0x0, sc=0x76971120) at dmd/escape.d:592
#2  0x5581f676 in ExpressionSemanticVisitor::visit(NewExp*)
(this=0x7fffbc78, exp=0x77e9f2f0) at dmd/expressionsem.d:2363
#3  0x55810d66 in NewExp::accept(Visitor*) (this=0x77e9f2f0,
v=0x7fffbc78) at dmd/expression.d:4155
#4  0x5583461f in expressionSemantic(Expression*, Scope*)
(e=0x77e9f2f0, sc=0x76971120) at dmd/expressionsem.d:9367
#5  0x558c5042 in StatementSemanticVisitor::visit(ExpStatement*)
(this=0x7fffbd48, s=0x77e9f360) at dmd/statementsem.d:177
#6  0x558a771a in ExpStatement::accept(Visitor*) (this=0x77e9f360,
v=0x7fffbd48) at dmd/statement.d:715
#7  0x558c4f2b in statementSemantic(Statement*, Scope*)
(s=0x77e9f360, sc=0x76971120) at dmd/statementsem.d:126
#8  0x558c52f0 in StatementSemanticVisitor::visit(CompoundStatement*)
(this=0x7fffc048, cs=0x77e9f380) at dmd/statementsem.d:235
#9  0x558a7ece in CompoundStatement::accept(Visitor*)
(this=0x77e9f380, v=0x7fffc048) at dmd/statement.d:908
#10 0x558c4f2b in statementSemantic(Statement*, Scope*)
(s=0x77e9f380, sc=0x76971120) at dmd/statementsem.d:126
#11 0x558d9d38 in Semantic3Visitor::visit(FuncDeclaration*)
(this=0x7fffc990, funcdecl=0x77e9efa0) at dmd/semantic3.d:581
#12 0x5583b80a in FuncDeclaration::accept(Visitor*)
(this=0x77e9efa0, v=0x7fffc990) at dmd/func.d:2277
#13 0x558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x77e9efa0,
sc=0x76970e30) at dmd/semantic3.d:82
#14 0x558d8a24 in Semantic3Visitor::visit(Module*)
(this=0x7fffca40, mod=0x77e9eb60) at dmd/semantic3.d:195
#15 0x557cfbf2 in Module::accept(Visitor*) (this=0x77e9eb60,
v=0x7fffca40) at dmd/dmodule.d:1322
#16 0x558d862d in semantic3(Dsymbol*, Scope*) (dsym=0x77e9eb60,
sc=0x0) at dmd/semantic3.d:82
#17 0x5587268b in dmd.mars.tryMain(ulong, const(char)**)
(argv=0x7fffd628, argc=3) at dmd/mars.d:836
#18 0x5587380f in D main () at dmd/mars.d:1098
```

However, with ddemangle everything is properly demangle:

```
gdbbt ../generated/linux/release/64/dmd -dip1000 foo.d | ddemangle
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
DMD v2.079.0-285-g5bdf4078c DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x55806135 in void dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7fffb730, e=0x0) at dmd/escape.d:1293
1293e.accept(v);
#0  0x55806135 in void
dmd.escape.escapeByValue(dmd.expression.Expression,
dmd.escape.EscapeByResults*) (er=0x7fffb730, e=0x0) at dmd/escape.d:1293
#1  0x558052b9 in bool dmd.escape.checkNewEscape(dmd.dscope.Scope*,
dmd.expression.Expression, bool) (gag=false, e=0x0, sc=0x76971120) at
dmd/escape.d:592
#2  0x5581f676 in ExpressionSemanticVisitor::visit(NewExp*)
(this=0x7fffbc78, exp=0x77e9f2f0) at dmd/expressionsem.d:2363
```

--

[Issue 18691] assigning a std.regex.Captures with 3 or more groups causes double free

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
I can't reproduce the crash neither with 2.079 nor with master (in valgrind
too).
And the same for run.dlang.io: https://run.dlang.io/is/2ncpH0


Is there anything specific about your setup?

--

[Issue 17918] [Reg 2.072] ICE with unknown symbol in base class

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

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

--- Comment #6 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8096

--

[Issue 18691] New: assigning a std.regex.Captures with 3 or more groups causes double free

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

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

  Issue ID: 18691
   Summary: assigning a std.regex.Captures with 3 or more groups
causes double free
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: martin.do...@hitachivantara.com

This minimal test case crashes:

martind@swiftboat:~/tmp/D134366$ cat utilimal.d 
import std.regex;

void main() {
auto rx = regex("()()()");
auto ma = "".matchFirst(rx);
ma = "".matchFirst(rx);
}
martind@swiftboat:~/tmp/D134366$
~/download/d/dmd/generated/linux/release/64/dmd -g utilimal.d && valgrind
./utilimal
...
==655== Invalid free() / delete / delete[] / realloc()
==655==at 0x4C29E90: free (vg_replace_malloc.c:473)
==655==by 0x4C1E26: _D3std5regex__T8CapturesTAyaZQo6__dtorMFNbNiNeZv
(/home/martind/download/d/dmd/generated/linux/release/64/../../../../../phobos/std/regex/package.d:565)
==655==by 0x48A1CB: _Dmain (utilimal.d:5)
==655==by 0x4C6F5F:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv (in
/home/martind/tmp/D134366/utilimal)
==655==by 0x4C6DEF: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv
(in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C6ECE: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in
/home/martind/tmp/D134366/utilimal)
==655==by 0x4C6DEF: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv
(in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C6D5A: _d_run_main (in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C303D: main (in /home/martind/tmp/D134366/utilimal)
==655==  Address 0x5d2be50 is 0 bytes inside a block of size 64 free'd
==655==at 0x4C29E90: free (vg_replace_malloc.c:473)
==655==by 0x4C1E26: _D3std5regex__T8CapturesTAyaZQo6__dtorMFNbNiNeZv
(/home/martind/download/d/dmd/generated/linux/release/64/../../../../../phobos/std/regex/package.d:565)
==655==by 0x4C2D2F:
_D3std5regex__T8CapturesTAyaZQo__T8opAssignZQkMFNbNiNeSQCbQCa__TQBxTQBrZQCfZQw
(/home/martind/download/d/dmd/generated/linux/release/64/../../../../../phobos/std/regex/package.d:685)
==655==by 0x48A181: _Dmain (utilimal.d:6)
==655==by 0x4C6F5F:
_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv (in
/home/martind/tmp/D134366/utilimal)
==655==by 0x4C6DEF: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv
(in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C6ECE: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv (in
/home/martind/tmp/D134366/utilimal)
==655==by 0x4C6DEF: _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ7tryExecMFMDFZvZv
(in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C6D5A: _d_run_main (in /home/martind/tmp/D134366/utilimal)
==655==by 0x4C303D: main (in /home/martind/tmp/D134366/utilimal)

My testing suggests that this is a regression in 2.079.0 over 2.078.3-0.  I
might risk a guess that it's due to the addition of opAssign to the Captures
struct in:

https://github.com/dlang/phobos/commit/59520969ef73eaf0691972ee00b389e5bbc4c8fb#diff-4715499b2ff2d74e4eb3c6f3909c611c
in an attempt by @MartinNowak to "fix Issue 18114 - regex performance
regression".  Do we now have big_matches in two Captures objects referring to
the same calloc/free memory but each with their own _refcount?  Have we also
leaked any old memory that (lhs) big_matches owned?

--

Re: Why is the class ._dtor symbol not virtual?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, March 28, 2018 20:17:28 12345swordy via Digitalmars-d wrote:
> I quite curious on the rational behind the decision, as currently
> it's not very attribute friendly, which makes destroy function
> @nogc for certain classes downright near impossible. From the
> time that I have looked into this issue(and from frequent
> discussions) many of the issues and bugs is the result of this
> bizarre design decision.

I think that this is the first that I've heard of them not being virtual,
but if I had to guess, the reason is that class finalizers are called by the
GC, and their TypeInfo is probably used, which would make it unnecessary for
the finalizer to be virtual, because it would always be called directly
rather than through a base class reference. But that's just a guess.

However, I don't understand why that would make the finalizer interact badly
with attributes. If the finalizer is not virtual, then the attributes for
each finalizer should be independent of one another. The reason that
attributes and classes are normally a problem is because you're restricted
by the attributes that were chosen for the base class function, and your
options for choosing different attributes for the function in a derived
class are limited.

As for issues with destroy in particular, remember that classes were
designed to be constructed and allocated using the GC and then destroyed and
freed by the GC. All of the stuff that tries to deal with any of that
without the GC came later - including using destroy to destroy an object
rather than waiting for the GC to do it. So, it's not exactly surprising if
there were design decisions made that don't play well with something like
destroy. Hopefully, any such problems can be fixed, but stuff like destroy
is trying to work around how classes were designed to be used.

- Jonathan M Davis

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 23:42:26 UTC, Simen Kjærås wrote:

On Wednesday, 28 March 2018 at 23:02:53 UTC, Chris Katko wrote:

There's many things that can be done to make the code easier to 
follow. These lines:

[...]


[...]


WOW. Thank you. That's the kind of tricks for (or more properly: 
knowledge of) templates that I can use. That's much more clean 
looking and maintainable. Feel free to recommend more 
ideas/tricks!


I'm still definitely working on improving (and developing) that 
template/function so yeah, I left those duplicate static if's in 
at the time (I called it "quits" after getting it to actually 
compile, so there's still scribble in there.)

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

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

On Wed, Mar 28, 2018 at 04:29:28PM -0700, Walter Bright via 
Digitalmars-d-announce wrote:
> On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:
> > Safety - not so much.
> 
> I remember back in the olden dayz when Microsoft was pushing ActiveX
> controls hard. ActiveX controls were blobs of code automatically
> downloaded from the internet that were embedded in your spreadsheet,
> word document, etc.
> 
> What could possibly go wrong? :-)

+1.

And today, even after Javascript-delivered Meltdown, people still don't
get it. *shrug*


T

-- 
MASM = Mana Ada Sistem, Man!

Re: Static Foreach + Marking "compile time" variables

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

On Wednesday, 28 March 2018 at 23:02:53 UTC, Chris Katko wrote:

There's many things that can be done to make the code easier to 
follow. These lines:

static if (!hasPosition)
{
assert(0, "Need to pass a position!");
}


Can be replaced with this:

static assert(hasPosition, "Need to pass a position");

That will show the error message at compile-time, greatly 
improving the experience of using the code. You could also us it 
as a template constraint:


void funct2(A...)(ALLEGRO_BITMAP *bit, A a)
if (anySatisfy!(isa!Position, A))
{

There are benefits and drawbacks to using template constraints 
vs. static asserts, so try both and see which fits your code.



Since hasPosition needs to be true for anything else to work, we 
can just assert it once, then assume it's true, turning these:



static if (hasPosition && hasCenteredPosition)
static if (hasPosition && hasRotate && !hasScale)


into these:

static if (hasCenteredPosition)
static if (hasRotate && !hasScale)


Another possible simplification in your code would be to use 
staticIndexOf instead of anySatisfy:


enum position = staticIndexOf!(pos, A);
static assert(position > -1, "Must pass a position");
enum hasCenteredPosition = anySatisfy!(isa!center, A);

static if (hasCenteredPosition) {
float temp_x = a[position].x - bit.w/2;
float temp_y = a[position].y - bit.h/2;
} else {
float temp_x = a[position].x;
float temp_y = a[position].y;
}

In fact, given the style in which you write your code, I would 
suggest these helper templates:


// Returns the first element of Args that is of type T,
// or an empty AliasSeq if no such element exists.
template find(T, Args...) {
enum idx = staticIndexOf!(T, typeof(Args));
static if (idx > -1) alias find = Args[idx];
else alias find = AliasSeq!();
}

// Checks if find!() found anything.
enum found(T...) = T.length == 1;


Using those, you would write this code:

void funct2(A...)(ALLEGRO_BITMAP* bit, A a)
if (anySatisfy!(isa!pos, A)
{
enum centered  = anySatisfy!(isa!center, A)

alias position = find!(pos, a);
alias rotation = find!(rotate, a);
alias scaling  = find!(scale, a);

static if (centered) {
// No need to use array lookup - find!() did that for us.
// That also means we can more easily modify position 
directly,

// instead of using temporaries.
position.x -= bit.w/2;
position.y -= bit.h/2;
}

static if (!found!rotation && !found!scaling) {
// Since rotation and scaling are empty AliasSeqs here,
// attempting to use them will cause immediate compile 
errors.

al_draw_bitmap(bit, position.x, position.y, 0);
} else static if (found!rotation && !found!scaling) {
al_draw_rotated_bitmap(bit,
bit.w/2,bit.h/2,
position.x, position.y,
rotation.a,
0);
} else static if (found!rotation && found!scaling) {
// Handle this case.
} else static if (!found!rotation && found!scaling) {
// Handle this case.
}
}

--
  Simen

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

[Walter Bright via Digitalmars-d-announce]

On 3/28/2018 1:50 PM, Dmitry Olshansky wrote:

Safety - not so much.


I remember back in the olden dayz when Microsoft was pushing ActiveX controls 
hard. ActiveX controls were blobs of code automatically downloaded from the 
internet that were embedded in your spreadsheet, word document, etc.


What could possibly go wrong? :-)

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

[Walter Bright via Digitalmars-d-announce]

On 3/28/2018 1:27 PM, Jacob Carlborg wrote:
There's usually nothing that prevents the build tool to write files at build 
time. Dub can do this.


It's expected with a build tool. Not a compiler.

Re: unittests, dub and libraries

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, March 28, 2018 21:29:22 Jesse Phillips via Digitalmars-d-learn 
wrote:
> On Wednesday, 28 March 2018 at 03:07:23 UTC, Jonathan M Davis
>
> wrote:
> > Run
> >
> > dub test
> >
> > The problem is that an executable needs a main, and a library
> > doesn't have one, whereas when you're testing a library, you
> > need an executable. So, a main must be inserted - e.g. with the
> > -main flag to dmd. Just building the unittest build doesn't
> > insert one. However, dub test _does_ deal with that for you.
> >
> > - Jonathan M Davis
>
> And a note on the reverse, if you have an executable project $
> dub test won't build in the app.d file since it contains main and
> dub test wants to avoid running your main function.

Yeah. That's really annoying behavior. I keep forgetting that it does that
until I realize that I have tests that should be failing that aren't.

- Jonathan M Davis

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 17:42:45 UTC, Steven Schveighoffer 
wrote:

On 3/28/18 11:46 AM, Chris Katko wrote:

 enum hasRotate = anySatisfy!( isa(pos), a);  //if of type 
"pos"


anySatisfy!(isa!pos, a)

anySatisfy takes a template alias (in this case, an 
instantiation of isa with a specific type), and then applies 
the template to all the elements of the alias sequence, 
returning true if any statisfy.


-Steve


Yeah, that was one of my errors during my 4 AM binge. But I 
forgot/missed to update that when I posted.


So far, everything is working with some dummy calls, and now I 
just have to start doing the annoying work of writing the code.


It's just... I wish it was a little more elegant. Right now, I'm 
stuck with like tons of static if cases. [see code at end of 
post] If I add "centered position" vs "position" now, I have to 
figure out how to add that into a single compound statement to 
fit into a unique static if. As opposed to simply, "if centered 
pos, take position, and just change it by subtracting width and 
height."  In that case, I can get away with leaving them run-time 
statements, but more complex features not-so-much. The point is 
to use compile-time/static/templates to build the correct 
statement. Because at the core of what I'm doing... it IS all 
statically / compile-time knowable information.


And having TONS of static ifs means there's TONS of room for 
human error as its maintained.


If I wrote a Python/whatever script that pre-processed my D code 
from the AST, I'd have no theoretical reason to prevent me from 
doing this (though, clearly with much added frustration of 
implementation and debugging!).


I'm starting to wonder if a mixin will somehow help... hmm. I'm 
going to keep thinking about the problem.


Some code will probably help explain what I'm talking about:

funct2(g.tile_bmp, pos(100,100), scale(2), rotate(0.0f), 
center());


template isa(T){enum isa(U) = is(U == T); }

void funct2(A...)(ALLEGRO_BITMAP *bit, A a)
{
enum hasPosition = anySatisfy!(isa!(pos), typeof(a));
enum hasCenteredPosition = anySatisfy!(isa!(center), typeof(a));

enum hasRotate  = anySatisfy!(isa!(rotate), typeof(a));
enum hasScale   = anySatisfy!(isa!(scale), typeof(a));

static if (hasPosition && hasCenteredPosition)
{
float temp_x=a[staticIndexOf!(pos, typeof(a))].x - bit.w/2;
float temp_y=a[staticIndexOf!(pos, typeof(a))].y - bit.h/2;
}else{
float temp_x=a[staticIndexOf!(pos, typeof(a))].x;
float temp_y=a[staticIndexOf!(pos, typeof(a))].y;
}

static if (!hasPosition)
{
assert(0, "Need to pass a position!");
}

static if (hasPosition && !hasRotate && !hasScale)
{
// Stuff
pragma(msg, "Class 1");
writeln("x ", a[staticIndexOf!(pos, typeof(a))].x);
writeln("y ", a[staticIndexOf!(pos, typeof(a))].y);

al_draw_bitmap(bit,
temp_x,
temp_y,
0);
}

static if (hasPosition && hasRotate && !hasScale)
{
// Stuff
pragma(msg, "Class 2");
writeln("x ", a[staticIndexOf!(pos, typeof(a))].x);
writeln("y ", a[staticIndexOf!(pos, typeof(a))].y);

al_draw_rotated_bitmap(bit,
bit.w/2,
bit.h/2,
temp_x,
temp_y,
a[staticIndexOf!(rotate, typeof(a))].a,
0);

}


static if (hasPosition && !hasRotate && hasScale)
{
pragma(msg, "Class 3");
}

static if (hasPosition && hasRotate && hasScale)
{
pragma(msg, "Class 4");
}




}

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

[Cym13 via Digitalmars-d-announce]

On Wednesday, 28 March 2018 at 20:50:51 UTC, Dmitry Olshansky 
wrote:

On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily 
positive. THough I can't tell why from the top of my mind.


The act of compiling a buggy program not influence the global 
state of the computer. It should not be necessary to vet code 
downloaded from the internet before even compiling it to 
ensure it doesn't mess up the system.


The moment there is make or other build tool this is all futile.



CTFE should run in a sandbox. It must be safe to compile code.


I agree but mostly on the grounds of purity and 
reproducibility. It also enables caching and incremental builds.


Safety - not so much.


Indeed, even without such high level tools using the linker is 
dangerous due to issues that nobody wants to consider 
vulnerabilities.


For demo:

$ mkdir test ; cd test
$ echo 'import std.stdio; void main(){ writeln("test"); }' > 
test.d

$ ln -s shouldntexist test
$ dmd test.d
$ ls -l
total 760K
-rw-r--r-- 1 cym13 cym13   90 Mar 29 00:28 test.d
lrwxrwxrwx 1 cym13 cym13   13 Mar 29 00:33 test -> shouldntexist*
-rw-r--r-- 1 cym13 cym13  14K Mar 29 00:33 test.o
-rwxr-xr-x 1 cym13 cym13 740K Mar 29 00:33 shouldntexist*

This can easily lead to privilege escalation by creating 
sensitive files in specific locations with arbitrary content 
(~/.ssh/authorized_keys comes to mind).


Ok, this needs a specially crafted symlink, but it's one more 
thing to check before compiling anything... Compiling just can't 
reasonably be assumed to be secure (although I'd very much like 
it to be).

Re: unittests, dub and libraries

[Jesse Phillips via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 21:29:22 UTC, Jesse Phillips wrote:
And a note on the reverse, if you have an executable project $ 
dub test won't build in the app.d file since it contains main 
and dub test wants to avoid running your main function.


For reference:

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

Re: unittests, dub and libraries

[Jesse Phillips via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 03:07:23 UTC, Jonathan M Davis 
wrote:

Run

dub test

The problem is that an executable needs a main, and a library 
doesn't have one, whereas when you're testing a library, you 
need an executable. So, a main must be inserted - e.g. with the 
-main flag to dmd. Just building the unittest build doesn't 
insert one. However, dub test _does_ deal with that for you.


- Jonathan M Davis


And a note on the reverse, if you have an executable project $ 
dub test won't build in the app.d file since it contains main and 
dub test wants to avoid running your main function.

Re: vibe.d & nginx

[bauss via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 20:34:52 UTC, Adam D. Ruppe wrote:

On Wednesday, 28 March 2018 at 19:42:24 UTC, bauss wrote:
Can I just create multiple server sections in the config, even 
on the same port? Or is there something I have to be aware of?


Multiple nginx configs can live on the same external port, 
though they will need to be running on different internal ports 
(so the vibe thing runs on like port 9000 then 9001 then 9002 
etc, while the nginx things all run on port 80 and can use the 
server name or locations to disambiguate)


Yeah I got it working and figured it out.

Thank you though

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

[Dmitry Olshansky via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 21:49:16 UTC, Walter Bright wrote:

On 3/27/2018 5:11 AM, Guillaume Piolat wrote:
- ability to write file during CTFE is not necessarily 
positive. THough I can't tell why from the top of my mind.


The act of compiling a buggy program not influence the global 
state of the computer. It should not be necessary to vet code 
downloaded from the internet before even compiling it to ensure 
it doesn't mess up the system.


The moment there is make or other build tool this is all futile.



CTFE should run in a sandbox. It must be safe to compile code.


I agree but mostly on the grounds of purity and reproducibility. 
It also enables caching and incremental builds.


Safety - not so much.

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

[Timon Gehr via Digitalmars-d]

On 28.03.2018 20:20, Manu wrote:

On 28 March 2018 at 05:22, Timon Gehr via Digitalmars-d
 wrote:

On 27.03.2018 20:14, Manu wrote:


That's exactly what I've been saying. For like, 9 years..
It looks like this:

https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
   (contribution appreciated)



"Temporary destruction
Destruction of any temporaries occurs naturally at the end of the scope, as
usual."

This is actually unusual.
 ...

...
So, what's wrong?
...


In my example, the temporary is destroyed after/at the end of the 
function call, not at the end of the scope.


Re-reading the DIP, I think you meant the right thing, but the wording 
is a bit confusing. Maybe just clarify that "the scope" is the one your 
rewrite introduces implicitly, or explicitly state that the lifetime 
ends at the end of the function call.





"Overload resolution
...



Note that lvalues prefer the ref overload because the ref overload is more
specialized. The new rule is the only instance where a less specialized
overload is preferred.


I've never heard any discussion involving the term 'specialised', or
seen any definition where overloading prefers a "more specialised'
version... is that a thing?
Given:
   void f(int);
   void f(const(int));
   f(10);

That calls the 'int' one, but it could call either one...


The overload resolution rules in D have four different matching levels:

- exact match
- match with type qualifier conversion
- match with general implicit conversion
- no match

The matching level for one overload is the minimal matching level for 
any argument. In your example f(int) matches exactly, but f(const(int)) 
matches with type qualifier conversion, therefore f(int) is chosen as it 
is the unique function that matches best.


Only if two overloads match with the same best level is specialization 
used. An overload A is more specialized than another overload B if we 
can call B with all arguments with which we can call A. As it is 
possible to call a by-value function with an lvalue or an rvalue, but 
ref cannot be called with an rvalue, ref is more specialized.



that's definitely not choosing a 'more specialised' match.
...


Implicit conversions are ignored when checking for specialization so, 
yes, here both functions are equally specialized. However, f(int*) is 
more specialized than f(const(int)*):


---
import std.stdio;

void f(int* a){
writeln("A");
}
void f(const(int)* b){
writeln("B");
}

void main(){
f(new immutable(int)); // guess what this prints. :)
}
---

Re: vibe.d & nginx

[bauss via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 19:42:24 UTC, bauss wrote:
I know how to setup nginx to a single vibe.d application, but 
what if I host multiple vibe.d applications on the same host.


How can I forward them using nginx correctly?

Can I just create multiple server sections in the config, even 
on the same port? Or is there something I have to be aware of?


Figured it out.

Re: vibe.d & nginx

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 19:42:24 UTC, bauss wrote:
Can I just create multiple server sections in the config, even 
on the same port? Or is there something I have to be aware of?


Multiple nginx configs can live on the same external port, though 
they will need to be running on different internal ports (so the 
vibe thing runs on like port 9000 then 9001 then 9002 etc, while 
the nginx things all run on port 80 and can use the server name 
or locations to disambiguate)

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

[Jacob Carlborg via Digitalmars-d-announce]

On 2018-03-27 23:49, Walter Bright wrote:

The act of compiling a buggy program not influence the global state of 
the computer. It should not be necessary to vet code downloaded from the 
internet before even compiling it to ensure it doesn't mess up the system.


There's usually nothing that prevents the build tool to write files at 
build time. Dub can do this.


--
/Jacob Carlborg

Why is the class ._dtor symbol not virtual?

[12345swordy via Digitalmars-d]

I quite curious on the rational behind the decision, as currently 
it's not very attribute friendly, which makes destroy function 
@nogc for certain classes downright near impossible. From the 
time that I have looked into this issue(and from frequent 
discussions) many of the issues and bugs is the result of this 
bizarre design decision.

[Issue 18690] New: Can't compare timezones for equality in @safe code

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

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

  Issue ID: 18690
   Summary: Can't compare timezones for equality in @safe code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: dhase...@gmail.com

---
void main() @safe
{
import std.datetime;
auto a = UTC();
auto b = UTC();
assert(a == b);
}
---

Expected result: the program compiles and runs. The assertion passes.

Actual result: tzcomp.d(6): Error: @safe function D main cannot call @system
function object.opEquals

I worked around this problem by adding a @trusted function that just checks
whether a timezone is equal to UTC.

This is a part of the general trend that Object.equals isn't inout, but no fix
for that is likely to come soon.

--

Re: Building application with LDC and -flto=thin fails in link stage

[Johan Engelen via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 17:03:07 UTC, Seb wrote:


dub supports dflags and lflags in the config file. lflags are 
the linker commands.


Please read the thread.

`lflags` is for passing flags to the _linker_ (i.e. those flags 
are prefixed with -L when passed to the _compiler_)


Here, what's needed is passing flags to the _compiler_ when it is 
invoked to perform the link step in the build.


-Johan

vibe.d & nginx

[bauss via Digitalmars-d-learn]

I know how to setup nginx to a single vibe.d application, but 
what if I host multiple vibe.d applications on the same host.


How can I forward them using nginx correctly?

Can I just create multiple server sections in the config, even on 
the same port? Or is there something I have to be aware of?

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

[Manu via Digitalmars-d]

On 28 March 2018 at 05:38, Timon Gehr via Digitalmars-d
 wrote:
> On 27.03.2018 22:25, Rubn wrote:
>>
>>
>> D already has move semantics, an easy solution to this is to just use
>> another keyword. It doesn't have to bind to const ref to get what is
>> desired:
>>
>> // what was suggested in the original DIP, since scope is being used for
>> something else now
>> void foo(@temp ref value)
>> {
>> }
>>
>> Now you don't have this problem. You only get this behavior when you
>> basically say you don't care whether it is a temporary or not.
>
> Another benefit of this solution is that the overload resolution rules are
> obvious. foo(@temp ref T value) is less specialized than both foo(T value)
> and foo(ref T value).
>
> @Manu: Consider this.

This defeats the entire point to me. I want symmetrical calling code
in all cases... the current edges are a massive pain in the arse.
In the event of yet-another-attribute, then we just shift the set of
edge cases onto that attribute instead, and it makes no practical
difference in the end.

[OT] - Re: Could someone take a look at DIP PR 109?

[Nick Treleaven via Digitalmars-d]

On Wednesday, 28 March 2018 at 06:43:15 UTC, Shachar Shemesh 
wrote:

For those too lazy to click on the link,


BTW It's not the reader's 'laziness', it's basic courtesy on the 
part of the poster to the newsgroup to provide a meaningful 
subject line for a thread. Far more people will read the subject 
line than the person writing it. How is anyone supposed to 
remember what PR #109 is (even if they do monitor the dlang/DIPs 
repo)? People don't want to have to open every thread and scan 
for clues or click on links just to know if the thread is about 
something they find interesting.


(Don't take this rant personally, many people are guilty of not 
providing a good descriptive subject).


Thanks for writing the DIP though ;-)

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

[Manu via Digitalmars-d]

On 28 March 2018 at 05:22, Timon Gehr via Digitalmars-d
 wrote:
> On 27.03.2018 20:14, Manu wrote:
>>
>> That's exactly what I've been saying. For like, 9 years..
>> It looks like this:
>>
>> https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md
>>   (contribution appreciated)
>
>
> "Temporary destruction
> Destruction of any temporaries occurs naturally at the end of the scope, as
> usual."
>
> This is actually unusual.
>
> ---
> import std.stdio;
> struct S{
> ~this(){
> writeln("destroyed!");
> }
> }
>
> void foo(S s){}
>
> void main(){
> foo(S());
> writeln("end the scope");
> }
> ---
>
> prints:
>
> destroyed!
> end the scope

Right, exactly...
So, what's wrong?


> "Overload resolution
> ...
> This follows existing language rules. No change is proposed here."
>
> Yes, you _are_ proposing a change. Right now rvalues "prefer" the by-value
> overload because the ref overload _does not match at all_. Now you make it
> match both, so you are adding additional disambiguation rules. You need to
> be more explicit about those.

Oh right... yeah okay, I'll tweak the language.


> Note that lvalues prefer the ref overload because the ref overload is more
> specialized. The new rule is the only instance where a less specialized
> overload is preferred.

I've never heard any discussion involving the term 'specialised', or
seen any definition where overloading prefers a "more specialised'
version... is that a thing?
Given:
  void f(int);
  void f(const(int));
  f(10);

That calls the 'int' one, but it could call either one... that's
definitely not choosing a 'more specialised' match.


> You also need to specify the interactions with matching levels
> (https://dlang.org/spec/function.html#function-overloading):
>
> E.g., your DIP is compatible with the following behavior:
>
> ---
> import std.stdio;
>
> struct S{}
> void fun(S){ writeln("A"); }
> void fun(ref const(S)){ writeln("B"); }
>
> void main(){
> fun(S()); // calls A
> S s;
> fun(s); // calls A
>
> const(S) t;
> fun(t); // calls B
> fun(const(S)()); // calls B
> }
> ---
>
> The first example will cause friction when people try to add an explicit
> rvalue overload alongside a previous catch-it-all overload, the second
> example shows a breaking language change.
>
> You cannot "fix" the first example without introducing breaking language
> changes. The above code compiles and runs in current D.
>
> This just smells bad. Remove the "const" requirement.

This is very compelling reason to remove the const.

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 17:08:39 UTC, Chris Katko wrote:

On Wednesday, 28 March 2018 at 15:49:39 UTC, Chris Katko wrote:

On Wednesday, 28 March 2018 at 15:46:42 UTC, Chris Katko wrote:

[...]


Whoops! Wrong error message. That's if I replace isa(pos) with 
IsIntegral.


[...]


Okay, the key appears to be here:

funct2(123); //a function call

void funct2(A...)(A a)
{
enum hasRotate = isIntegral!(a[0]); // NOPE!
}

//E: template instance isIntegral!(_param_0) does not match 
template declaration isIntegral(T)


But if I do:

funct2!(123); //note !

I get

//E: tuple A is used as a type



GOT IT!!

I needed typeof on the right side.

template isa(T){enum isa(U) = is(U == T); }

funct2(g.tile_bmp, pos(100,100), scale(2), rotate(0.0f));

void funct2(A...)(ALLEGRO_BITMAP *bit, A a)
{
enum hasPosition= anySatisfy!(isa!(pos), typeof(a));
}

Works!

Re: Static Foreach + Marking "compile time" variables

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/28/18 11:46 AM, Chris Katko wrote:


 enum hasRotate = anySatisfy!( isa(pos), a);  //if of type "pos"


anySatisfy!(isa!pos, a)

anySatisfy takes a template alias (in this case, an instantiation of isa 
with a specific type), and then applies the template to all the elements 
of the alias sequence, returning true if any statisfy.


-Steve

[Issue 18602] [Better C] docs

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

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

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

https://github.com/dlang/dlang.org/commit/46f9117d0cd5cd2ad66d9b89f61bb1c324002a32
Fix Issue 18602 - [Better C] docs (duplicate "Dynamic arrays")

> "Dynamic arrays" shows up in both "Retained Features" and "Not Available" 
> sections

https://github.com/dlang/dlang.org/commit/b413e09a7f66315ca2c17115cd5370701b9c6079
Merge pull request #2302 from wilzbach/fix-18602

Fix Issue 18602 - [Better C] docs (duplicate "Dynamic arrays")

--

[Issue 18602] [Better C] docs

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

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

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

   What|Removed |Added

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

--

[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

--- Comment #3 from Jonathan M Davis  ---
(In reply to Jack Stouffer from comment #2)
> If opCmp is defined but opEquals isn't, doesn't DMD re-write `val == val` to
> `val.opCmp(val) == 0`?

No. The only way to override == and != is opEquals. e.g. this code runs and
passes just fine:

struct S
{
int opCmp(S rhs)
{
assert(0);
}
}

void main()
{
assert(S.init == S.init);
}

If opCmp is consistent with the default opEquals, then there is no need to
define opEquals, and opCmp will never be called for == or !=. If opCmp is not
consistent with the default opEquals, then opEquals needs to be defined. And if
opEquals is defined, then toHash needs to be defined. But as long as opEquals
isn't defined, then the default toHash should work just fine.

--

[Issue 18676] std.datetime.date.DateTime has opEquals but no toHash

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
DateTime does not define opEquals. It uses the default. If you meant opCmp like
you said on the other bug reports referring to std.datetime.date, I ask what I
asked there:

Why does it matter if opCmp is defined and not toHash? It's if opEquals is
defined that toHash is required, not opCmp.

--

[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

--- Comment #2 from Jack Stouffer  ---
(In reply to Jonathan M Davis from comment #1)
> Why does it matter if opCmp is defined and not toHash? It's if opEquals is
> defined that toHash is required, not opCmp.

If opCmp is defined but opEquals isn't, doesn't DMD re-write `val == val` to
`val.opCmp(val) == 0`?

--

[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
Why does it matter if opCmp is defined and not toHash? It's if opEquals is
defined that toHash is required, not opCmp.

--

[Issue 18677] std.datetime.date.Date has opCmp but no toHash

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

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #1 from Jonathan M Davis  ---
Why does it matter if opCmp is defined and not toHash? It's if opEquals is
defined that toHash is required, not opCmp.

--

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 15:49:39 UTC, Chris Katko wrote:

On Wednesday, 28 March 2018 at 15:46:42 UTC, Chris Katko wrote:

[...]


Whoops! Wrong error message. That's if I replace isa(pos) with 
IsIntegral.


[...]


Okay, the key appears to be here:

funct2(123); //a function call

void funct2(A...)(A a)
{
enum hasRotate = isIntegral!(a[0]); // NOPE!
}

//E: template instance isIntegral!(_param_0) does not match 
template declaration isIntegral(T)


But if I do:

funct2!(123); //note !

I get

//E: tuple A is used as a type

Re: Building application with LDC and -flto=thin fails in link stage

[Seb via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 16:42:23 UTC, Johan Engelen wrote:

On Tuesday, 27 March 2018 at 22:10:33 UTC, Per Nordlöw wrote:

On Tuesday, 27 March 2018 at 22:00:42 UTC, Johan Engelen wrote:

Indeed.
Please try to manually link first (without dub) by modifying 
the command on which dub errors:


```
ldmd2 -flto=thin 
-of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2

```

-Johan


Yes, that works!


Good :-)

I'm no dub expert and I don't know how to pass flags to the 
_compiler_ for the link step.

Would be good to figure that out with the dub folks.

There will be similar problems with using ASan (and fuzzer 
aswell):  `-fsanitize=address` must also be passed to the D 
compiler (not the linker) during linking such that the correct 
asan library is linked into the executable.


- Johan


dub supports dflags and lflags in the config file. lflags are the 
linker commands.


http://code.dlang.org/package-format?lang=sdl#build-settings

You can also specify per platform arguments, e.g.

dflags "-version=BuildingWithLDCRocks" platform="ldc"

(dub even supports the environment variables DFLAGS which dmd 
doesn't (and of course LFLAGS))

Re: Building application with LDC and -flto=thin fails in link stage

[Johan Engelen via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 22:10:33 UTC, Per Nordlöw wrote:

On Tuesday, 27 March 2018 at 22:00:42 UTC, Johan Engelen wrote:

Indeed.
Please try to manually link first (without dub) by modifying 
the command on which dub errors:


```
ldmd2 -flto=thin 
-of.dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery .dub/build/application-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F2904BE3C4DA237C077E5C2B0B23442E/knetquery.o ../../.dub/packages/gmp-d-master/gmp-d/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-B287F67CE5FF6145BC229790CFB09607/libgmp-d.a phobos-next/.dub/build/library-release-nobounds-lto-linux.posix-x86_64-ldc_2078-F0F2FDB01B8401C04D657BCC145D46A5/libknet_phobos-next.a -L--no-as-needed -L-lzstd -L-lgmp -L-lc -L-lreadline -L-lz -L-lbz2

```

-Johan


Yes, that works!


Good :-)

I'm no dub expert and I don't know how to pass flags to the 
_compiler_ for the link step.

Would be good to figure that out with the dub folks.

There will be similar problems with using ASan (and fuzzer 
aswell):  `-fsanitize=address` must also be passed to the D 
compiler (not the linker) during linking such that the correct 
asan library is linked into the executable.


- Johan

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

[Manu via Digitalmars-d]

On 28 Mar. 2018 4:35 am, "Timon Gehr via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:

On 27.03.2018 20:14, Manu wrote:

> That's exactly what I've been saying. For like, 9 years..
> It looks like this:
> https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx
> -rval_to_ref.md
>   (contribution appreciated)
>
> As far as I can tell, it's completely benign, it just eliminates the
> annoying edge cases when interacting with functions that take
> arguments by ref. There's no spill-over affect anywhere that I'm aware
> of, and if you can find a single wart, I definitely want to know about
> it.
>

???


I've asked so many times for a technical destruction, nobody will
> present any opposition that is anything other than a rejection *in
> principle*. This is a holy war, not a technical one.
>

That's extremely unfair. It is just a bad idea to overload D const for this
purpose. Remove the "const" requirement and I'm on board.


I discussed that in that document. I'm happy to remove const, but it
requires a value judgement on the meaning of non-const in this case. It
becomes controversial without const, but I'm personally happy to remove it
if you can make The argument in favour. Can you give me some ideas where it
would be useful?

Re: Fixing 18615, how to handle @safe/pure/nothrow test breakage due to object.opEquals?

[SimonN via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 15:04:27 UTC, Kagamin wrote:

See line 1957, attributes are not inferred.


Wow, that hit my blind spot. :-O Thanks. I've moved the 
RebindableCommon.opEquals outside of the attributes and all tests 
pass, as expected.


-- Simon

[Issue 18689] New: std.format should always throw FormatException on bad specs/arguments

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

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

  Issue ID: 18689
   Summary: std.format should always throw FormatException on bad
specs/arguments
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

void main()
{
import std.exception : assertThrown;
import std.format : format, FormatException;
assertThrown!FormatException(format("%d", "foo")); // fails
}

--

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 15:46:42 UTC, Chris Katko wrote:

On Wednesday, 28 March 2018 at 08:05:55 UTC, Simen Kjærås wrote:

On Wednesday, 28 March 2018 at 07:45:59 UTC, Chris Katko wrote:
I have a static foreach that goes through the parameter list 
and if it sees a class like "rotate", ideally, I want it to 
mark a boolean "has_rotate=true"


Then simply later on, once I've parsed the list, I pick an 
output path:


static if(has_rotate && has_position && has_scale)
{
//call C function al_draw_rotated_scaled_bitmap(...);
}

So I pass a bunch of "options" and then based on those 
options, it picks the right function to call instead of me 
manually writing 
draw_fixed_centered_rotated_scaled_colored_compressed_bitmap() manually.


The problem is, I can foreach through those parameters all 
just fine... but I can't "set" a marker.


The error message makes perfect sense in retrospect:

 variable has_position cannot be read at compile time

has_position isn't a static/compile-time variable. The 
question is... do they exist in D? Because otherwise, I'll be 
going from a really clean, elegant solution that simply 
passes through each parameter, and then reacts to the 
combined result, and end up with something that has to "step 
toward" the result, or perhaps, test every possible 
permutation individually--so as to not need variables.


D does not have compile-time variables. The way you'd 
generally do what you describe is with the templates in 
std.meta. Instead of something like this:


bool hasRotate= false;
static foreach (e; MyTuple) {
hasRotate |= is(e == Rotate);
}
static if (hasRotate) { // Fails, since b is a runtime 
variable.

// Stuff
}

You'd be using a more functional style:

template isa(T) {
enum isa(U) = is(U == T);
}

enum hasRotate = anySatisfy!(isa!Rotate, MyTuple);
static if (hasRotate) {
// Stuff
}

--
  Simen


Thank you for the reply! But I'm unable to get that code to 
compile. For example:


/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_1) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(888): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_1) error 
instantiating
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)
/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_2) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(888): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_2) error 
instantiating
/usr/local/bin/../import/std/meta.d(889):instantiated 
from here: anySatisfy!(isIntegral, _param_2, _param_3)
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)
/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_3) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(889): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_3) error 
instantiating
/usr/local/bin/../import/std/meta.d(889):instantiated 
from here: anySatisfy!(isIntegral, _param_2, _param_3)
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)



Perhaps I should post more of my code because there may be 
subtle differences that are important:


struct pos{float x, y;}
struct scale{float f;}
struct rotate{ float a; }

void test_inst()
{
funct2(tile_bmp, pos(100,100), scale(2), rotate(0.0f));
//this worked with the foreach version
// in the case that it compiled and read the arguments
}

Then I use your version:

template isa(T) {
enum isa(U) = is(U == T); //is(typeof(U) == T)  doesn't 
work either.

 }

void funct2(A...)(ALLEGRO_BITMAP *bitmap_bmp, A a)
{
enum hasRotate = anySatisfy!( isa(pos), a);  //if of type "pos"
static if (hasRotate)
{
// Stuff
}
}


Whoops! Wrong error message. That's if I replace isa(pos) with 
IsIntegral.


If I have isa(pos). It's almost identical:

/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_1) does not match template declaration isa(U)
/usr/local/bin/../import/std/meta.d(888): Error: template 
instance extra.funct2!(int, int, int).funct2.anySatisfy!(isa, 
_param_1) error instantiating
extra.d(263):instantiated from here: anySatisfy!(isa, 
_param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)

Re: Static Foreach + Marking "compile time" variables

[Chris Katko via Digitalmars-d-learn]

On Wednesday, 28 March 2018 at 08:05:55 UTC, Simen Kjærås wrote:

On Wednesday, 28 March 2018 at 07:45:59 UTC, Chris Katko wrote:
I have a static foreach that goes through the parameter list 
and if it sees a class like "rotate", ideally, I want it to 
mark a boolean "has_rotate=true"


Then simply later on, once I've parsed the list, I pick an 
output path:


static if(has_rotate && has_position && has_scale)
{
//call C function al_draw_rotated_scaled_bitmap(...);
}

So I pass a bunch of "options" and then based on those 
options, it picks the right function to call instead of me 
manually writing 
draw_fixed_centered_rotated_scaled_colored_compressed_bitmap() 
manually.


The problem is, I can foreach through those parameters all 
just fine... but I can't "set" a marker.


The error message makes perfect sense in retrospect:

 variable has_position cannot be read at compile time

has_position isn't a static/compile-time variable. The 
question is... do they exist in D? Because otherwise, I'll be 
going from a really clean, elegant solution that simply passes 
through each parameter, and then reacts to the combined 
result, and end up with something that has to "step toward" 
the result, or perhaps, test every possible permutation 
individually--so as to not need variables.


D does not have compile-time variables. The way you'd generally 
do what you describe is with the templates in std.meta. Instead 
of something like this:


bool hasRotate= false;
static foreach (e; MyTuple) {
hasRotate |= is(e == Rotate);
}
static if (hasRotate) { // Fails, since b is a runtime 
variable.

// Stuff
}

You'd be using a more functional style:

template isa(T) {
enum isa(U) = is(U == T);
}

enum hasRotate = anySatisfy!(isa!Rotate, MyTuple);
static if (hasRotate) {
// Stuff
}

--
  Simen


Thank you for the reply! But I'm unable to get that code to 
compile. For example:


/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_1) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(888): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_1) error instantiating
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)
/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_2) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(888): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_2) error instantiating
/usr/local/bin/../import/std/meta.d(889):instantiated 
from here: anySatisfy!(isIntegral, _param_2, _param_3)
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)
/usr/local/bin/../import/std/meta.d(883): Error: template 
instance F!(_param_3) does not match template declaration 
isIntegral(T)
/usr/local/bin/../import/std/meta.d(889): Error: template 
instance extra.funct2!(int, int, 
int).funct2.anySatisfy!(isIntegral, _param_3) error instantiating
/usr/local/bin/../import/std/meta.d(889):instantiated 
from here: anySatisfy!(isIntegral, _param_2, _param_3)
extra.d(264):instantiated from here: 
anySatisfy!(isIntegral, _param_1, _param_2, _param_3)
extra.d(385):instantiated from here: funct2!(int, int, 
int)



Perhaps I should post more of my code because there may be subtle 
differences that are important:


struct pos{float x, y;}
struct scale{float f;}
struct rotate{ float a; }

void test_inst()
{
funct2(tile_bmp, pos(100,100), scale(2), rotate(0.0f));
//this worked with the foreach version
// in the case that it compiled and read the arguments
}

Then I use your version:

template isa(T) {
enum isa(U) = is(U == T); //is(typeof(U) == T)  doesn't 
work either.

 }

void funct2(A...)(ALLEGRO_BITMAP *bitmap_bmp, A a)
{
enum hasRotate = anySatisfy!( isa(pos), a);  //if of type "pos"
static if (hasRotate)
{
// Stuff
}
}

Re: "in" no longer "scope" since 2.079.0?

[Kagamin via Digitalmars-d-learn]

On Tuesday, 27 March 2018 at 09:58:11 UTC, bauss wrote:
So now "in" is basically just an alias and serves no real 
purpose or is there a plan to eventually make "in" mean 
something other than just "const"?


At this point it's the spec that serves no real purpose, 
sometimes in is scope, sometimes it isn't and sometimes scope is 
not scope either. I don't think any decision was made on this, 
it's just PRs getting merged as long as tests pass.

Re: Fixing 18615, how to handle @safe/pure/nothrow test breakage due to object.opEquals?

[Kagamin via Digitalmars-d-learn]

See line 1957, attributes are not inferred.

[Issue 18474] Postblit not working in shared structs

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #3 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/8098

Also, if someone is interested, I documented the (bugish) behavior of the
postblit: https://dlang.org/spec/struct.html#struct-postblit

--

[Issue 18688] New: Constructors shouldn't have implicit super call if it throws

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

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

  Issue ID: 18688
   Summary: Constructors shouldn't have implicit super call if it
throws
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: yshu...@gmail.com

This example doesn't compile:

class A {
this(int x){}
@disable this();
}
class B: A {
this(int x) {
super(x);
}
this(string b) {
switch(b) {
case "a":break;
default: assert(false);
}
this(1);
}
}

Possibly because the compile decides 'this(1)' is not always reachable, and
tries to implicitly call super() in that case. But if 'this(1)' is not
reachable, the constructor is guaranteed to throw, thus super call should not
be required.

Also, this program has almost the same behavior (SwitchError is thrown instead
of AssertError), but it compiles:

class A {
this(int x){}
@disable this();
}
class B: A {
this(int x) {
super(x);
}
this(string b) {
final switch(b) {
case "a":break;
}
this(1);
}
}

--

[Issue 18671] Implement loop unrolling in dmd's optimizer

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

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18685] std.containers.slist.SList has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or neither are defined

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Depends on||18679, 18680, 18681, 18682,
   ||18683, 18684, 18685, 18686,
   ||18687
Summary|Checks that opEquals and|[Tracking] Check that
   |toHash are both defined or  |opEquals and toHash are
   |neither are defined |both defined or neither are
   ||defined


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18679
[Issue 18679] std.complex.opEquals has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18680
[Issue 18680] std.random.LinearCongruentialEngine has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18681
[Issue 18681] std.random.XorshiftEngine has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18682
[Issue 18682] std.typecons.Nullable has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18683
[Issue 18683] std.containers.rbtree.RedBlackTree has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18684
[Issue 18684] std.containers.array.Array has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18685
[Issue 18685] std.containers.slist.SList has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18686
[Issue 18686] std.containers.dlist.DList has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18687
[Issue 18687] std.numeric.CustomFloat has opEquals but no toHash
--

[Issue 18682] std.typecons.Nullable has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18687] std.numeric.CustomFloat has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18683] std.containers.rbtree.RedBlackTree has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18681] std.random.XorshiftEngine has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18679] std.complex.opEquals has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18680] std.random.LinearCongruentialEngine has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18684] std.containers.array.Array has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18686] std.containers.dlist.DList has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] [Tracking] Check that opEquals and toHash are both defined or
neither are defined
--

[Issue 18687] New: std.numeric.CustomFloat has opEquals but no toHash

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

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

  Issue ID: 18687
   Summary: std.numeric.CustomFloat has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18686] New: std.containers.dlist.DList has opEquals but no toHash

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

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

  Issue ID: 18686
   Summary: std.containers.dlist.DList has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18685] New: std.containers.slist.SList has opEquals but no toHash

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

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

  Issue ID: 18685
   Summary: std.containers.slist.SList has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18684] New: std.containers.array.Array has opEquals but no toHash

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

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

  Issue ID: 18684
   Summary: std.containers.array.Array has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18683] New: std.containers.rbtree.RedBlackTree has opEquals but no toHash

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

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

  Issue ID: 18683
   Summary: std.containers.rbtree.RedBlackTree has opEquals but no
toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18682] New: std.typecons.Nullable has opEquals but no toHash

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

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

  Issue ID: 18682
   Summary: std.typecons.Nullable has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18681] New: std.random.XorshiftEngine has opEquals but no toHash

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

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

  Issue ID: 18681
   Summary: std.random.XorshiftEngine has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18680] New: std.random.LinearCongruentialEngine has opEquals but no toHash

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

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

  Issue ID: 18680
   Summary: std.random.LinearCongruentialEngine has opEquals but
no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18679] New: std.complex.opEquals has opEquals but no toHash

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

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

  Issue ID: 18679
   Summary: std.complex.opEquals has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18676] std.datetime.date.DateTime has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 18674] std.json.JSONValue has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 18677] std.datetime.date.Date has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 17206] Checks that opEquals and toHash are both defined or neither are defined

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Depends on||18674, 18675, 18676, 18677,
   ||18678


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18674
[Issue 18674] std.json.JSONValue has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18675
[Issue 18675] std.experimental.checkedint.Checked has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18676
[Issue 18676] std.datetime.date.DateTime has opEquals but no toHash
https://issues.dlang.org/show_bug.cgi?id=18677
[Issue 18677] std.datetime.date.Date has opCmp but no toHash
https://issues.dlang.org/show_bug.cgi?id=18678
[Issue 18678] std.datetime.date.TimeOfDay has opCmp but no toHash
--

[Issue 18678] New: std.datetime.date.TimeOfDay has opCmp but no toHash

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

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

  Issue ID: 18678
   Summary: std.datetime.date.TimeOfDay has opCmp but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18677] New: std.datetime.date.Date has opCmp but no toHash

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

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

  Issue ID: 18677
   Summary: std.datetime.date.Date has opCmp but no toHash
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18677] std.datetime.date.Date has opCmp but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Mac OS X|All
   Severity|enhancement |normal

--

[Issue 18676] New: std.datetime.date.DateTime has opEquals but no toHash

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

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

  Issue ID: 18676
   Summary: std.datetime.date.DateTime has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18675] New: std.experimental.checkedint.Checked has opEquals but no toHash

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

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

  Issue ID: 18675
   Summary: std.experimental.checkedint.Checked has opEquals but
no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18674] New: std.json.JSONValue has opEquals but no toHash

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

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

  Issue ID: 18674
   Summary: std.json.JSONValue has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 18673] std.socket.InternetAddress has opEquals but no toHash

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Blocks||17206


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=17206
[Issue 17206] Checks that opEquals and toHash are both defined or neither are
defined
--

[Issue 17206] Checks that opEquals and toHash are both defined or neither are defined

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

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

Jack Stouffer  changed:

   What|Removed |Added

 Depends on||18673


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=18673
[Issue 18673] std.socket.InternetAddress has opEquals but no toHash
--

[Issue 17206] Checks that opEquals and toHash are both defined or neither are defined

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

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|enhancement |normal

--- Comment #1 from Jack Stouffer  ---
I'm turning this into a tracking issue.

--

[Issue 18673] New: std.socket.InternetAddress has opEquals but no toHash

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

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

  Issue ID: 18673
   Summary: std.socket.InternetAddress has opEquals but no toHash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

Fixing 18615, how to handle @safe/pure/nothrow test breakage due to object.opEquals?

[SimonN via Digitalmars-d-learn]

Hi,

I'm trying to fix Bugzilla 18615, Rebindable!A doesn't use class 
A's opEquals (returns a is b instead) [1]. The fix looks 
reasonably obvious, my code is at [2]. Most of the added lines is 
the unittest; the essence of the fix is:


struct RebindableCommon(/* ... */)
{
// ...
bool opEquals(ref const(typeof(this)) rhs) const
{
return this.original == rhs.original;
}
}

But this breaks several existing unittests throughout Phobos 
because the comparison in object.d lacks @safe, @nogc, nothrow 
and pure. For example, unittests in systime.d fail:


pure function [...]RebindableCommon[...].opEquals cannot call 
impure function object.opEquals

nothrow function [...]RebindableCommon[...].opEquals may throw
std/datetime/systime.d(9006): Error: template instance 
`std.typecons.Rebindable!(immutable(TimeZone))` error 
instantiating


I'd rather not add attributes to the Rebindable.opEquals because 
this function sits in a templated struct RebindableCommon, where 
the compiler should deduce attributes automatically.


But I don't want to remove correct attributes from unittests in 
systime.d either.


Can I reasonably continue here to fix 18615?

-- Simon

[1] https://issues.dlang.org/show_bug.cgi?id=18615
[2] 
https://github.com/SimonN/phobos/commit/5a6fc6fd905b02e5ff93f2aaeaee2487fe8b38d0

Re: Manipulate slice or specific element of range and return range

[Timoses via Digitalmars-d-learn]

On Thursday, 22 March 2018 at 07:34:18 UTC, David Bennett wrote:

On Thursday, 22 March 2018 at 04:49:39 UTC, Seb wrote:

```
alias lowercased = (m, n) => 
m.take(n).asLowerCase.chain(m.drop(n));

```


```
string input = "My Capital String";
auto lower1 = 
input.take(1).asLowerCase.chain(input.drop(1).filter!(c => c != 
' ')).array;

assert(lower1 == "myCapitalString");
```

Also a few more options (including a slice version):

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

As the input is never read until the array() is run, each 
element in the array should only be copied from RAM to the 
stack once.


And if you compile with LDC a lot of it can be inlined and the 
stack copies of the range structs and elements should be 
minimised even further.


Very inspiring snippets!