[Issue 17426] New: "version(none):" cant be overwritten by its counterpart

[via Digitalmars-d-bugs]

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

  Issue ID: 17426
   Summary: "version(none):" cant be overwritten by its
counterpart
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

this test cast should crash at run-time

dmd veroverwrite.d -main -unittest

veroverwrite.d:

---
version(none):
unittest {assert(false);}
version(all):
unittest {assert(false);} // not compiled
version(none):
unittest {assert(false);}
---

--

Re: My two cents on what D needs to be more successful...

[rikki cattermole via Digitalmars-d]

On 24/05/2017 5:04 AM, Adam D. Ruppe wrote:

On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:

http://code.dlang.org/packages/arsd


So actually, the dub thing for mine is

http://code.dlang.org/packages/arsd-official/~master

the other was a third party thing that is now obsolete (and imo this
shows one of the weaknesses of dub right now... the list order is just
most recent explicit update and old things can't be removed afaik)


They can be removed, but that means projects stop being built hence not 
wanting to remove them.

Re: My two cents on what D needs to be more successful...

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:

http://code.dlang.org/packages/arsd


So actually, the dub thing for mine is

http://code.dlang.org/packages/arsd-official/~master

the other was a third party thing that is now obsolete (and imo 
this shows one of the weaknesses of dub right now... the list 
order is just most recent explicit update and old things can't be 
removed afaik)



  - std.input (get mouse/touchscreen/etc events)


Honestly you are better off with using SDL.


oh my simpledisplay does that too! and 2d/3d drawing. and 
combined with minigui does user interface (though minigui still 
isn't quite done)



I am tempted to package my stuff with dmd as a one-stop 
download... but idk if it is really beneficial since my stuff is 
so easy to download and use anyway with my policy of independent 
files.

Re: Ali's slides from his C++Now talk

[Ali Çehreli via Digitalmars-d]

On 05/23/2017 07:42 PM, Jack Stouffer wrote:

On Wednesday, 24 May 2017 at 00:05:54 UTC, Ali Çehreli wrote:

...


Any videos up?



Not yet but I heard the videos will be posted here:

  https://www.youtube.com/user/BoostCon

Ali

Re: DIP 1008 Preliminary Review Round 1

[Jack Stouffer via Digitalmars-d]

On Monday, 22 May 2017 at 12:00:30 UTC, Nick Treleaven wrote:
//FIXME: uniqueToString should return @nogc UniquePtr!(const 
char[])

import std.conv;
alias uniqueToString = to!(const char[]);

class MessageEx(E, sinkArgs...) : E
{
this(A...)(A args)
{
super(args);
}

//FIXME: delegate not @nogc
/*@nogc*/ override void toString(scope void delegate(in 
char[]) sink) const

{
foreach (a; sinkArgs)
sink(uniqueToString(a));
}
}

unittest
{
auto x = 7;
throw new MessageEx!(Exception, "x = ", x)(null);
}

The result of uniqueToString would free any memory allocated 
after the call to sink.


Heh, I actually ran into this problem earlier today and just saw 
this post https://issues.dlang.org/show_bug.cgi?id=17420


Weird coincidence.

[Issue 17425] New: add __traits(getParameterStorageClasses, f, i)

[via Digitalmars-d-bugs]

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

  Issue ID: 17425
   Summary: add __traits(getParameterStorageClasses, f, i)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

This returns a tuple of strings representing the storage classes of the ith
parameter of function f. 0 represents the first parameter.

The order of the strings in the tuple should not be depended upon.

This is intended to replace the implementation of
std.traits.ParameterStorageClassTuple(f)

--

Re: DMD VS2017 Support

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:
Come one, let's be ones: If DMD has no x64 linker, VS 
integration is not a bit optional.


Unlike some other operating systems, 64-bit Windows versions can 
run 32-bit software just fine. If you require targeting Win64 (or 
the Microsoft C runtime), that is specific to your use case.


And, again, Visual Studio is not required if you want to target 
Win64 - only the necessary toolchain components (linker and C 
runtime), which you can also obtain from an SDK.


So you are telling me "not working at all" is not worth 
releasing a fix? xD


Again, everything should be already working. We are talking about 
a convenience feature that automatically sets up the D compiler's 
configuration file, nothing more. That's all there is to the 
"integration". You can trivially do the same thing by hand, or 
set up your environment accordingly - all in a fraction of the 
time it took you to write these pointless complaints on this 
forum.

Re: Ali's slides from his C++Now talk

[Jack Stouffer via Digitalmars-d]

On Wednesday, 24 May 2017 at 00:05:54 UTC, Ali Çehreli wrote:

...


Any videos up?

Re: Any video editing folks n da house?

[rikki cattermole via Digitalmars-d]

On 23/05/2017 9:23 PM, Andrei Alexandrescu wrote:

Would be great to have a video intro of D featuring a mix of testimonies
from a few folks, fragments from the existing DConf materials, etc. Some
of that cool ukulele upbeat music, too. Anyone would enjoy taking up
such a project? -- Andrei


If you can provide the raw footage, I'm sure a few of us will give it a 
go (I have licenses for music which I can use for this stuff).

[Issue 17424] Add useful warnings

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan M Davis  ---
(In reply to greenify from comment #1)
> Great idea. This is one of the areas where D is definitely behind other
> languages.
> IIRC Walter believes that the compiler isn't a linter, so if I am not
> mistaken only warnings with minimal or zero overhead will be merged.

His take on it is that warnings are a sign that folks couldn't agree on what
was right or wrong in the language. He tends to think that something should
either be an error or not (and I agree with him). But the issue of warnings has
been discussed many times in the newsgroup, and I really don't think that many
are going to be added to the compiler. And the fact that dmd stupidly has -w
makes them that much worse because of how that affects compile-time
introspection.

Ultimately though, the big problem with warnings is that if you're doing your
job right, you fix them all (if you don't, you just end up with a big pile of
warnings that get ignored and so you miss whatever value they do provide), and
so you might as well either make them errors or not warn about them at all. And
it gets _very_ annoying when the compiler warns about something that shouldn't
need to be changed. Really, anything that's going to be optional makes far more
sense in a linter.

I can certainly appreciate not wanting to compile your code twice (once to get
your executable and once to be told about potential - but not definite -
problems in your code), but IMHO, it really doesn't make sense for the compiler
to be warning about optional things. And I've never seen it be anything but a
disaster in practice with any other language. _Best_ case, you're stuck
"fixing" all kinds of stuff that isn't actually wrong so that you don't have
any warnings, but more often, you end up with tons of warnings that no one pays
attention to. Having at tool that can warn about potential problems has real
value, but I don't think that it's appropriate for the compiler to be doing it.

> Ideally
> Dscanner (https://github.com/dlang-community/D-Scanner) should be able to
> yield such warnings, but with it's current status as (a pure parser without
> any semantical analysis) many of your warnings will be hard to achieve.
> Hence, I guess the least controversial option is to introduce these warnings
> step by step with a new opt-in flag in the D fronted.

Walter is also very much against additional compiler flags. So, I think that
you're going to have a hard time convincing him that this is a good idea.
Having the compiler as a library as has been discussed would make it easier to
write a linter, but based on past discussions on this topic, I think that it's
pretty clear that the vast majority of these suggestions will never be compiler
warnings even if they make a lot of good sense for a linter.

--

[Issue 17421] add __traits(getFunctionVariadicStyle, f)

[via Digitalmars-d-bugs]

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

--- Comment #3 from Walter Bright  ---
https://github.com/dlang/phobos/pull/5424

--

[Issue 17421] add __traits(getFunctionVariadicStyle, f)

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--

Re: Trip notes from Israel

[bpr via Digitalmars-d-announce]

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ -- 
Andrei


That was a great read, thanks!

At the end, you mention a successful serial entrepreneur who 
counsels pursuing the great rather than the good ideas being 
advanced in the D community. Did he happen to mention which ideas 
were great, and which just good?

[Issue 17424] Add useful warnings

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
Great idea. This is one of the areas where D is definitely behind other
languages.
IIRC Walter believes that the compiler isn't a linter, so if I am not mistaken
only warnings with minimal or zero overhead will be merged. Ideally Dscanner
(https://github.com/dlang-community/D-Scanner) should be able to yield such
warnings, but with it's current status as (a pure parser without any semantical
analysis) many of your warnings will be hard to achieve. Hence, I guess the
least controversial option is to introduce these warnings step by step with a
new opt-in flag in the D fronted.

--

Re: My two cents on what D needs to be more successful...

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 23 May 2017 at 22:14:22 UTC, Ecstatic Coder wrote:


I tried to explained that with this post, and what could be a 
solution for that problem, but obviously that was pointless.


Hi,

You'll find agreement here. I wasn't framing my answer as a 
criticism of your post, which I think is well balanced. The 
leadership believes in a larger standard library too.


I just wanted to increase awareness of the (sometimes 
outstanding) libraries there is in the dub registry, that can be 
used right now. Some of it are below the radar but worthwhile.

[Issue 17424] New: Add useful warnings

[via Digitalmars-d-bugs]

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

  Issue ID: 17424
   Summary: Add useful warnings
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

I have debugged many bugs for many hours that would have been caught by a
simple warning in C or C++.

Here are a few warnings I'd really like to see when building D code.

* Unused parameter -- of course you should be able to say "intentionally
unused" (underscore prefix to name? a uda?)

* Unused imports -- this is super important to keep incremental compile times
down

* Copying a large value (more than given threshold) - when passing parameters,
in assignments, etc. Can always use explicit copy functions instead, pass by
ref, etc.

* Allocating a large value on the stack (more than given threshold) - very
useful for fibers with small stacks.

* Unused definitions/types: a function is not reachable by any non-private
definition -- some uda should allow overriding this

* Signed/unsigned comparisons

* Function is @nogc but not marked as such

* Function is pure but not marked as such

* Function is nothrow but not marked as such

* Function is const but not marked as such

* Code was determined to be dead (will never be executed)

* Use of implicitly initialized variable (for variables implicitly set to
.init), at least for floats/doubles where NaN is likely to be bug-prone.

* Use of voided variable (for variables init'd with =void)

* Constructor may throw - no automatic destruction will occur

* Conditional used is always true/false and compiled out -- must be able to
wash away known-good instances

It doesn't matter if they are opt-in warnings, opt-out/always errors, or a
separate compiler-library thing -- but ideally I wouldn't need to run all the
CTFE twice just to get my warnings.

--

Re: Ali's slides from his C++Now talk

[Ali Çehreli via Digitalmars-d]

On 05/23/2017 04:31 PM, Joakim wrote:

Enjoying going through these:

http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantage_with_D.no_pause.pdf


Ali really has a gift for explaining stuff, we're lucky to have him.


Let me be the first to say that the presentation had many no-nos:

- Walls of text

- Walls of code

- Too much material

Probably that's why it "reads" good. ;)

Ali

[Issue 16301] CTFE execution of opApply keeps wrong "this" context in foreach's body

[via Digitalmars-d-bugs]

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

--- Comment #10 from Eyal  ---
Sorry, this is the actual example that showed the dynamic scoping lookup in the
PR is incorrect:

@safe:

unittest {
enum Caller { OpApply, Other }
struct OpApply {
@safe:
int delegate(Caller) @safe myDlg;
int opApply(int delegate(Caller) @safe dlg) {
myDlg = dlg;
return dlg(Caller.OpApply);
}
}
struct Foo {
@safe:
OpApply o;
int i;
this(int x) {
i = x;
o = OpApply();
foreach(caller; o) {
final switch(caller) {
case Caller.OpApply:
if(i == 1) {
auto foo2 = Foo(2);
assert(2 == foo2.call(o.myDlg));
assert(i == 0);
}
break;
case Caller.Other:
i = 0;
break;
}
}
}

int call(int delegate(Caller) @safe dlg) {
dlg(Caller.Other);
return i;
}
}
Foo(1);
}

The distilled one somehow

--

[Issue 16301] CTFE execution of opApply keeps wrong "this" context in foreach's body

[via Digitalmars-d-bugs]

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

--- Comment #9 from Eyal  ---
In the code review I saw that the PR changed the CTFE to use dynamic scoping
lookup instead of lexical scoping so after much IRC back and forth I eventually
managed to distill the problematic example to:

@safe:

unittest {
struct Foo {
@safe:
int i;
int whoami() { return i; }
int call(int delegate() @safe dlg) {
return dlg();
}
}
int func() {
auto foo1 = Foo(1);
auto foo2 = Foo(2);
assert(1 == foo2.call());
return 0;
}
enum F = func();
}

--

Tilix 1.5.8 released

[Gerald via Digitalmars-d-announce]

Tilix 1.5.8 is now available with a number of new features and 
bug fixes. For those unfamiliar with Tilix, it is a tiling 
terminal emulator for Linux written in D using GTK3. It attempts 
to follow the Gnome Human Interface Guidelines as closely as 
possible. More information about Tilix is available here:


https://gnunn1.github.io/tilix-web

One word of caution, this version of Tilix has been upgraded to 
using PCRE2 for regular expressions when the VTE version 
indicates it is supported. Unfortunately Ubuntu 17.10 removed 
this functionality from VTE and hence Tilix is broken on 17.10 
until Ubuntu patches Tilix in their distribution. See issue 
[#916](https://github.com/gnunn1/tilix/issues/916) for more 
information.


Other notable changes for this release include:

* Can detach sessions by dragging them off the sidebar to the 
desktop. Can re-attach sessions by dragging them from the sidebar 
to another tilix window
* Can re-order sessions via drag and drop in sidebar or by using 
ctrl-pgup or ctrl-pagedn
* If ctrl-c is assigned to the copy shortcut, tilix is smart 
enough to only copy when text is selected otherwise normal 
interrupt is passed
* Window state is now restored on new launch, i.e. if window is 
maximized and closed it will be maximized when new instance is 
launched
* Added new variable for titles at session scope for active 
terminal title
* Added support for GTK active CSS style to enable better styling 
of terminal titlebars

* Added support for pending VTE hyperlink functionality (#904)

As always, any D developers interested in contributing to Tilix 
are more then welcome to do so. Feel free to contact me if 
interested.

[Issue 15318] Templates not emitted for two "partial cycles"

[via Digitalmars-d-bugs]

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

--- Comment #9 from David Nadlinger  ---
(In reply to Johan Engelen from comment #7)
> It appears this was fixed for the OP testcase in DMD 2.072.

Let's hope it is actually fixed, rather than just not occurring anymore in the
test case. ;)

--

Ali's slides from his C++Now talk

[Joakim via Digitalmars-d]

Enjoying going through these:

http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantage_with_D.no_pause.pdf

Ali really has a gift for explaining stuff, we're lucky to have 
him.

[Issue 17423] @safe code seg faults

[via Digitalmars-d-bugs]

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

--- Comment #1 from Eyal  ---
I think foreach on delegates (opApply or delegates) should require the delegate
parameter to be marked "scope" since it really must not escape.

--

Re: DMD VS2017 Support

[Jolly James via Digitalmars-d]

On Monday, 22 May 2017 at 23:58:37 UTC, Vladimir Panteleev wrote:
Additionally, Visual Studio integration is an optional feature 
of the Windows version, and of course VS2017 is just one 
supported version of VS.
Come one, let's be ones: If DMD has no x64 linker, VS integration 
is not a bit optional.


The scope of the problem may seem larger to you because you are 
affected by it personally, however at any point in time there 
may be any number of fixes queued for release of similar 
relative importance. Making an urgent release for every such 
occurrence would be impractical, if not impossible given the 
necessary work involved with making each new release.


So you are telling me "not working at all" is not worth releasing 
a fix? xD

Re: templatized delegate

[Alex via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 16:38:14 UTC, Stanislav Blinov wrote:
Ah, now I think I get it. You want to store a single delegate 
that could be called with different sets of arguments? No, you 
can't do that: you need an actual delegate instance, and for 
that, you need to know the signature, at least when 
instantiating C.


Yes :)
or, just to differentiate between the used and unused parameters, 
without loosing their types and attributes.

But that's a minor problem, the solution with full signature

https://forum.dlang.org/post/ekbpjsuyqprusyasm...@forum.dlang.org#post-svvgcrymplmyondhuogt:40forum.dlang.org

works also well, as the effort to name everything is not so big 
in my case...

Re: templatized delegate

[Alex via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 18:14:34 UTC, ag0aep6g wrote:

Something like this:


import core.vararg;
import std.meta: AliasSeq, staticMap;
import std.traits: isCopyable;

struct A
{
void delegate(...) dg;
auto fun(T, U ...)(T t, auto ref U u)
{
template UncopyableToPointer(T)
{
static if (!isCopyable!T) alias UncopyableToPointer 
= T*;

else alias UncopyableToPointer = T;
}
alias U2 = staticMap!(UncopyableToPointer, U);

U2 u2;
foreach (i, E; U)
{
static if (!isCopyable!E) u2[i] = [i];
else u2[i] = u[i];
}

return dg(t, u2);
}
}

struct SomeStructThatIsNotCopyable
{
@disable this(this);
}

void main()
{
void dlg(...)
{
import std.stdio;
foreach (i, t; _arguments)
{
foreach (T; AliasSeq!(int, string,
SomeStructThatIsNotCopyable*))
{
if (t == typeid(T))
{
static if (is(T : U*, U) && !isCopyable!U)
{
write("uncopyable type");
}
else write(_argptr.va_arg!T);
}
}
/* otherwise: don't know how to handle the type */
write(" ");
}
writeln();
}

auto a = A();
SomeStructThatIsNotCopyable s;
a.fun(5, "a", /* by ref: */ s, /* or by pointer: */ );
}


That's not exactly pretty, of course. Both A.fun and the 
delegate are quite complicated. But it might be workable, if 
run-time variadics are acceptable.


I wouldn't be surprised if the problem can be solved more 
elegantly. But I don't see how at the moment.


That's cool :)
but anyway, even if I have such params, there are not much of 
them, so it just a minor semantic issue to explicitely name them 
and their types instead of showing, that they are passed but not 
used inside dlg.

And thanks a lot to all for great ideas :)

[Issue 17407] [REG] __traits(compiles) triggers assertion failure

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/ed8e853224800282396df5dd6b5dc1ae9e0db5b2
fix Issue 17407 - [REG] __traits(compiles) triggers assertion failure

https://github.com/dlang/dmd/commit/cf2f95461ae6e16e786232777162cf62b7da04ce
Merge pull request #6807 from WalterBright/fix17407

--

Re: DIP 1008 Preliminary Review Round 1

[Martin Nowak via Digitalmars-d]

On Friday, 19 May 2017 at 15:45:28 UTC, Mike Parker wrote:
Extensive discussion of this DIP has already taken place in two 
threads, both linked from the document. You may find it 
beneficial to skim through those threads before posting any 
feedback here.


Thanks in advance to all who participate.

Destroy!


The proposal is a very mechanical fix, throwing several special 
cases at one specific problem.
Why does it have to be refcounted? Seems like there is only ever 
one reference to the current exception (the catch variable).
The only thing that seems necessary is to require scope on catch 
variable declarations, so that people do not escape the class 
reference, then this info might be used by the runtime to free 
exception objects after the catch handler is done.


Amaury put a bit more words into that.
http://forum.dlang.org/post/gtqsojgqqaorubcsn...@forum.dlang.org

Has staticError been considered? It has a potential issue with 
multiple nested exceptions, but otherwise works fine.

https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683

Re: My two cents on what D needs to be more successful...

[Ecstatic Coder via Digitalmars-d]

So we just need ranking in code.dlang.org?


Again, I'm not saying that these libraries don't exist.

I'm saying that there are many alternatives to choose from, which 
is fine, but sometimes, not having to search, evaluate and test 
third-party libraries can be a benefit to the user of a new 
programming language.


It seems that I'm a good example of this kind of "dumb" 
programmer, who prefer to have everything already prepared.


Some people like to buy meat, vegetables etc, and cook all that 
to prepare lasagne or chinese food all by themselves.


Personally, my wife prepares these delicious dishes for me, and 
I'm perfectly happy with that.


Some people prefer that things are already prepared for them and 
immediately ready to use, some others don't, and prefer to do all 
the experiments by themselves until they have found exactly what 
is best for them.


Not everybody is the same, that's all what I'm saying.

And some of the programmers who try D might not like to take time 
searching for these libraries, and decide that D is not enough 
"operational" by their standard, whether it's true or not.


The problem is that all the people on this forum are by 
definition those who haven't rejected the D language for that 
reason.


I know at least two fellow programmers who tried it on my advice, 
and told me that "indeed D is nice but to do xxx it's still 
easier with yyy".


I tried to explained that with this post, and what could be a 
solution for that problem, but obviously that was pointless.

Beta D 2.074.1-b1

[Martin Nowak via Digitalmars-d-announce]

First beta for the 2.074.1 point release.

This version resolves a few regressions and bugs in the 2.074.0
release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.074.1.html

Please report any bugs at https://issues.dlang.org

-Martin

Re: Idea: Reverse Type Inference

[Timon Gehr via Digitalmars-d]

On 23.05.2017 16:55, Petar Kirov [ZombineDev] wrote:

On Monday, 22 May 2017 at 13:39:46 UTC, Timon Gehr wrote:

...
Another annoying case:

alias Fun(A,B) = B delegate(A);

B apply(A,B)(Fun!(A,B) f, A a){ return f(a); }

void main(){
apply(x=>x,2); // error
}


Interesting. BTW, what do you think about this feature being extended to 
implicit template instantiations a la Rust: 
https://doc.rust-lang.org/book/generics.html#resolving-ambiguities ?

...


This is easier to pull off in Rust, where generics are more limited and 
there are no implicit conversions, but it could work, to a useful 
extent. It's less likely to happen though, because so far, all type 
deduction happens locally (except attributes). I don't think the 
compiler is set up to very easily migrate to a system where type 
deduction and implicit template instantiation can happen at a distance.




In Kotlin they have a related feature called smart casts:
https://kotlinlang.org/docs/reference/typecasts.html
(also briefly shown here 
https://www.youtube.com/watch?v=X1RVYt2QKQE=1569s)

...


This is cheap for them to support, as everything is a class reference 
and they do null safety the same way. In D, not every type is a class, 
and language magic causes friction, so user-defined types would need to 
be able to customize such an analysis in some way. (E.g. typestate.)



Which of course is a subset of the more general area of control flow 
based type analysis. Typescript is good example of bringing those things 
to the JS world: https://www.youtube.com/watch?v=d1f6VBmWg6o=39m39s
https://blog.mariusschulz.com/2016/09/30/typescript-2-0-control-flow-based-type-analysis 



This only works really well if types do not implicitly affect execution. 
D has e.g. opAssign, based on the assumption that types of variables do 
not change. Also, in D, types are used to determine memory layout.



They don't seem to take it very far though. (E.g. it does not seem to 
support polymorphic record updates from what I can see).

[Issue 15824] 'scope' attribute ignored when making an alias to a scope delegate

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
As scope is a storage class, it cannot be part of a type or alias declaration,
i.e. just like ref you can add it for parameters and unlike ref, scope can be
used on variable declarations.

--

[Issue 17422] New: [scope] class reference not initialized as scope variable

[via Digitalmars-d-bugs]

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

  Issue ID: 17422
   Summary: [scope] class reference not initialized as scope
variable
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: safe
  Severity: normal
  Priority: P3
 Component: dmd
  Assignee: bugzi...@digitalmars.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
struct RC
{
Object get() return scope @trusted
{
return cast(Object) [0];
}

private:
ubyte[__traits(classInstanceSize, Object)] store;
}

Object test() @safe
{
RC rc;
auto p = rc.get; // p must be inferred as scope variable, works for int*
return p;
}
CODE
dmd -c bug -dip1000

Should raise an error but doesn't get catched by the compiler.

--

[Issue 16108] `to!string` fails on struct with disabled postblit

[via Digitalmars-d-bugs]

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

--- Comment #2 from Eyal  ---
This makes it slightly more painful to do some kinds of types representing
resources in D.

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

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

Eyal  changed:

   What|Removed |Added

 CC||e...@weka.io

--- Comment #7 from Eyal  ---
This bit us in several places in the weka codebase.

--

Re: My two cents on what D needs to be more successful...

[Guillaume Piolat via Digitalmars-d]

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:


  - std.database (connect/use MySQL/MongoDB/etc databases)


http://code.dlang.org/packages/arsd



  - std.web (serve web data/files/pages)


vibe.d
http://code.dlang.org/packages/arsd



  - std.audio (load/play/process/record sounds/musics)


http://code.dlang.org/?sort=updated=library.audio



  - std.image (load/show/process/record images)


http://code.dlang.org/packages/imageformats
http://code.dlang.org/packages/ae
http://code.dlang.org/packages/arsd



  - std.video (load/show/process/record videos)


http://code.dlang.org/packages/ae
I sometimes process video with command-line pipes using 
https://github.com/p0nce/y4m-tools



  - std.graphic (draw 2D/3D graphics)


http://code.dlang.org/packages/ae
Check out its explanation 
https://blog.thecybershadow.net/2014/03/21/functional-image-processing-in-d/




  - std.input (get mouse/touchscreen/etc events)


Honestly you are better off with using SDL.
http://code.dlang.org/packages/derelict-sdl2



  - std.ui (draw 2D user interfaces)

http://code.dlang.org/packages/dlangui


I agree that at the moment, all these developments can be 
possible through several third-party libraries.


So we just need ranking in code.dlang.org?

[Issue 17421] add __traits(getFunctionVariadicStyle, f)

[via Digitalmars-d-bugs]

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

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6825

--

Re: My two cents on what D needs to be more successful...

[Ecstatic Coder via Digitalmars-d]

On Tuesday, 23 May 2017 at 07:33:04 UTC, MGW wrote:

On Sunday, 21 May 2017 at 05:52:11 UTC, Ecstatic Coder wrote:

Since a few months, I'm using D for all my command-line tools.

I consider that D and phobos are quite ready for constant use. 
As for alternative libraries, I selected a way of integration 
with Qt. One Small example of my operation on Mac OSX, is mini 
IDE c use of Qt 5.


https://www.youtube.com/watch?v=JbvUJwShN_c
https://github.com/MGWL/QtE5


Thanks for proposing this C++ wrapper.

Qt will get the job done, obviously, so at least now I can 
implement my GUI with ease.


C++ back to the rescue ;)

Re: My two cents on what D needs to be more successful...

[Ecstatic Coder via Digitalmars-d]

Ok, I agree with what you say.

Indeed, it sounds logical to suppose that the developers of the 
best libraries in each domain won't probably accept that their 
work is adapted to be promoted to the status of standard 
libraries, just to keep the full control on them.


That's sad, because I still consider that D's popularity could 
improve a lot if it was also equipped "by default" to be a rapid 
application development environment for cross-platform connected 
web/desktop/mobile applications, but now I've clearly understood 
why this will never happen.

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

[Andrei Alexandrescu via Digitalmars-d]

On 05/23/2017 03:47 PM, Andrei Alexandrescu wrote:

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

Looking forward to more in the same vein, please contribute! We have 25 
left in phobos and 12 in druntime. A big one will be making the GC 
lazily initialize itself. -- Andrei


In the same vein: https://github.com/dlang/phobos/pull/5423 -- Andrei

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

[Andrei Alexandrescu via Digitalmars-d]

On 05/23/2017 04:34 PM, David Nadlinger wrote:

On Tuesday, 23 May 2017 at 19:47:49 UTC, Andrei Alexandrescu wrote:

A big one will be making the GC lazily initialize itself.


How detailed are your plans for this? The interaction between GC and 
shared library loading is a bit non-trivial to get right. — David


Not too detailed, and that why I'm counting for experts such as 
yourself. -- Andrei

Re: new contract syntax DIP

[MysticZach via Digitalmars-d]

On Tuesday, 23 May 2017 at 19:04:46 UTC, arturg wrote:

how about @uda based contracts?

@in(x => x < 100)
@out((ret) { assert(ret > 0, "some text"); })
int fun(int i) { return someVal; }

they could also be used on type definitions,

@out((t) { assert(t); })
 class NotNull {}

or temporarly on instances

@in(t => t !is null) auto notNull = new NotNull;

you could also have @inout as a combination.
another feature would be that they could be introspected.


Well I was going for three things:

1. contracts simple to write, with minimal "extra plumbing", i.e. 
without brackets and parentheses

2. utilize existing contract infrastructure
3. minimal divergence from existing syntax and semantics.

While not having to write `assert` in contracts would save a 
little space, it reduces what you can do with them, and also 
introduces a whole new semantics. The @uda contract system you 
suggest would require extensive description, documentation, and 
probably implementation effort. It would have to demonstrate that 
there was no better way to solve the problems it solves. (I'm not 
even sure I can justify my little syntax change, let alone a 
whole new semantics. I don't even know if contracts in general 
are important enough to be worth improving their syntax.)


So yeah, one could do things differently. But just because you 
_can_ do things differently doesn't mean you should. And 
justifying _why_ you should is not easy. And if people are being 
reasonable, they should maintain very high standards for what 
goes into a general-purpose programming language. Because there 
are a lot of things you can't take back once they're in there. 
(On the other hand, you don't want to stagnate, and not change 
_anything_, just for fear of making a mistake. One should strive 
for a balance.)

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

[David Nadlinger via Digitalmars-d]

On Tuesday, 23 May 2017 at 19:47:49 UTC, Andrei Alexandrescu 
wrote:

A big one will be making the GC lazily initialize itself.


How detailed are your plans for this? The interaction between GC 
and shared library loading is a bit non-trivial to get right. 
— David

Any video editing folks n da house?

[Andrei Alexandrescu via Digitalmars-d]

Would be great to have a video intro of D featuring a mix of testimonies 
from a few folks, fragments from the existing DConf materials, etc. Some 
of that cool ukulele upbeat music, too. Anyone would enjoy taking up 
such a project? -- Andrei

Simplifying druntime and phobos by getting rid of "shared static this()" blocks

[Andrei Alexandrescu via Digitalmars-d]

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

Looking forward to more in the same vein, please contribute! We have 25 
left in phobos and 12 in druntime. A big one will be making the GC 
lazily initialize itself. -- Andrei

way of the ninja

[talon via Digitalmars-d]

i hate this game but i beat it

Re: new contract syntax DIP

[arturg via Digitalmars-d]

On Tuesday, 23 May 2017 at 17:28:21 UTC, MysticZach wrote:
I made a pull request for a new DIP dealing with contract 
syntax:


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

I write the DIP in response to the discussions for DIP 1003: 
http://forum.dlang.org/thread/wcqebjzdjxldeywlx...@forum.dlang.org


This DIP is not under any kind of formal review yet. I just 
wanted to let people know that it's there.


how about @uda based contracts?

@in(x => x < 100)
@out((ret) { assert(ret > 0, "some text"); })
int fun(int i) { return someVal; }

they could also be used on type definitions,

@out((t) { assert(t); })
 class NotNull {}

or temporarly on instances

@in(t => t !is null) auto notNull = new NotNull;

you could also have @inout as a combination.
another feature would be that they could be introspected.

Re: why properties don't support +=, -= ... operators?

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 23 May 2017 at 17:38:18 UTC, Petar Kirov [ZombineDev] 
wrote:



AFAIU the OP, he's asking for the following lowering:

e.value += 42;
//   ^
//   v
e.value(e.value() + 42);

However, note that in general such lowering may not always be 
possible or desirable. For example:


e.someContainerProperty ~= new Item();
//   ^
//   v
e.someContainerProperty(e.someContainerProperty() ~ new Item());


Personally, I found long ago that this is a malpractice. If you 
need default behavior on assignment and op-assignment, you're 
better off with a public variable.
If you need *special* behavior on these operations, it's better 
to define them on the type level, rather than on the aggregate. 
Otherwise maintainability goes down rather quick. This is 
especially true for the case you mention, where not every 
operator makes sense.


One simple example is input validation:

auto defaultOp(string op, X, Y)(X x, Y y)
{
return mixin("x"~op~"y");
}

struct Validated(T, string name, alias V, T init = T.init)
{
private T value = init;

void opAssign(U)(U other)
{
// use introspection to find out if opAssign
// needs validation
static if (__traits(hasMember, Validated, 
"validateAssignment"))

value = validateAssignment(other);
else value = other;
}

void opOpAssign(string op,U)(U other)
{
// use introspection to find out if opOpAssign
// needs validation
static if (__traits(hasMember, Validated, 
"validateOpAssignment"))

value = validateOpAssignment!op(value, other);
else value = defaultOp!op(value, other);
}

T get() const { return value; }

alias get this;

string toString() const
{
import std.conv;
return to!string(value);
}

mixin V!name;
}

mixin template Property(T, string name, alias V, T init = T.init)
{
mixin("private Validated!(T, name, V, init) "~name~"_;");
mixin("ref auto "~name~"() inout { return "~name~"_; }");
}

struct Foo
{
mixin template myValidator(string name : "value")
{
import std.algorithm : among;
enum minValue = 0;
enum maxValue = 10;

auto validateAssignment(U)(U other)
{
if (other < minValue || other > maxValue)
throw new Exception("range violation");
return other;
}

// only allow += and -=
auto validateOpAssignment(string op, I, U)(I v, U other)
if(op.among("+", "-"))
{
const newVal = defaultOp!op(v, other);
if (newVal < minValue || newVal > maxValue)
throw new Exception("range violation");
return newVal;
}
}

mixin template myValidator(string name : "fval")
{
import std.math : isNaN;

auto validateAssignment(U)(U other)
{
if (other.isNan)
throw new Exception("not a number");
return other;
}

auto validateOpAssignment(string op, F, U)(F v, U other)
{
const newVal = defaultOp!op(v, other);
if (newVal.isNaN)
throw new Exception("not a number");
return newVal;
}
}

mixin template myValidator(string name : "str")
{
// does not define validateOpAssignment, default will be 
used


auto validateAssignment(U)(U other)
{
if (other is null)
throw new Exception("str cannot be null");
return other;
}
}

mixin Property!(string, "str",   myValidator, "hello");
mixin Property!(float,  "fval",  myValidator, 0); // floats 
are nan by default, we use 0

mixin Property!(int,"value", myValidator);
}

void main()
{
Foo foo;

import std.stdio;

writeln(foo.str);
foo.str = "happy";
foo.str ~= " coding";
writeln(foo.str);

foo.fval += 12.5;

(ref const Foo f) {
writeln(f.fval);
// will not compile, f is const
//f.fval -= 2;
} (foo);

writeln(foo.value);
foo.value += 5;

void takesInt(int v) { writeln("int: ", v); }
void takesFloat(float v) { writeln("float: ", v); }

takesInt(foo.value);
takesFloat(foo.fval);

// will not compile, we're not defining *=
//foo.value *= 10;
writeln(foo.value);
// will throw
foo.value += 6;
writeln(foo.value);
}

Sure, it looks more verbose than just checking the values inside 
a manually-written getter and setter, but the thing is, it's 
written once, and is reusable, whereas with getters and setters 
you end up wet (as in, the opposite of DRY) :)

[Issue 17421] add __traits(getFunctionVariadicStyle, f)

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--- Comment #1 from uplink.co...@googlemail.com ---
(In reply to Walter Bright from comment #0)
> This will cut down on the brittleness of std.traits.variadicFunctionStyle()
+1
I like this trend.

--

[Issue 17421] New: add __traits(getFunctionVariadicStyle, f)

[via Digitalmars-d-bugs]

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

  Issue ID: 17421
   Summary: add __traits(getFunctionVariadicStyle, f)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

This will cut down on the brittleness of std.traits.variadicFunctionStyle()

--

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Tuesday, 23 May 2017 at 17:46:23 UTC, Petar Kirov [ZombineDev] 
wrote:


Seems like you need to make -bc-ctfe the default in your dmd 
branch :P


That is what I usually do, however I re-enabled the switch in 
order to test which error messages the current Interpreter throws 
out.

Re: why properties don't support +=, -= ... operators?

[Andrey via Digitalmars-d]

On Tuesday, 23 May 2017 at 17:38:18 UTC, Petar Kirov [ZombineDev] 
wrote:
The problem is that if you return by ref you loose the ability 
to intercept the setting of the value, i.e. you're no better 
than just making the field public.


AFAIU the OP, he's asking for the following lowering:

e.value += 42;
//   ^
//   v
e.value(e.value() + 42);

However, note that in general such lowering may not always be 
possible or desirable. For example:


e.someContainerProperty ~= new Item();
//   ^
//   v
e.someContainerProperty(e.someContainerProperty() ~ new Item());


You right, it would be nice to explicitly set lowering.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

[Martin Nowak via Digitalmars-d]

On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote:

On 2/14/2017 8:25 AM, Andrei Alexandrescu wrote:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if (s != SwapStrategy.stable
&& isBidirectionalRange!Range
&& hasLvalueElements!Range
&& hasLength!Range
&& Offset.length >= 1);

The function name is on the first line.


It could be improved slightly using indentation:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if (s != SwapStrategy.stable
&& isBidirectionalRange!Range
&& hasLvalueElements!Range
&& hasLength!Range
&& Offset.length >= 1);

But there's another issue here. remove() has other overloads:

Range remove
(SwapStrategy s = SwapStrategy.stable, Range, Offset...)
(Range range, Offset offset)
if (s == SwapStrategy.stable
&& isBidirectionalRange!Range
&& hasLvalueElements!Range
&& Offset.length >= 1)

Range remove(alias pred, SwapStrategy s = SwapStrategy.stable, 
Range)

(Range range)
if (isBidirectionalRange!Range
&& hasLvalueElements!Range)

Two constraints are common to all three, those are the only 
ones that actually need to be in the constraint. The others can 
go in the body under `static if`, as the user need not be 
concerned with them.


Turns out that this advice is somewhat problematic. When the 
constraints are too general, it might easily attempt to hijack 
other calls, leading to conflicts between unrelated functions of 
the same name.


See https://github.com/dlang/phobos/pull/5149 which introduced a 
conflict between std.algorithm.copy and std.file.copy for 
(string, string) arguments.


Still your point is valid, separating different overloads using 
constraints unnecessarily complicates documentation.

Re: templatized delegate

[ag0aep6g via Digitalmars-d-learn]

On 05/23/2017 01:30 PM, Alex wrote:
And no, I can't pass it by adress, as I don't know apriori, whether the 
very parameter which gets the random generator is already a part of the 
variadic parameters, or a well defined ref parameter.


A (run-time) variadic delegate isn't flexible like that. When you have a 
`void delegate(...)`, then there are no non-variadic parameters. You 
know both in the caller and in the callee that passing by ref is not an 
option. So you can define that uncopyable types are passed by pointer.


Going this route means you have to make all your delegates variadic 
(this might be annoying). A.fun can remain a variadic template. It can 
also have ref parameters, but then you have to detect uncopyable types 
and pass pointers to the delegate.


Something like this:


import core.vararg;
import std.meta: AliasSeq, staticMap;
import std.traits: isCopyable;

struct A
{
void delegate(...) dg;
auto fun(T, U ...)(T t, auto ref U u)
{
template UncopyableToPointer(T)
{
static if (!isCopyable!T) alias UncopyableToPointer = T*;
else alias UncopyableToPointer = T;
}
alias U2 = staticMap!(UncopyableToPointer, U);

U2 u2;
foreach (i, E; U)
{
static if (!isCopyable!E) u2[i] = [i];
else u2[i] = u[i];
}

return dg(t, u2);
}
}

struct SomeStructThatIsNotCopyable
{
@disable this(this);
}

void main()
{
void dlg(...)
{
import std.stdio;
foreach (i, t; _arguments)
{
foreach (T; AliasSeq!(int, string,
SomeStructThatIsNotCopyable*))
{
if (t == typeid(T))
{
static if (is(T : U*, U) && !isCopyable!U)
{
write("uncopyable type");
}
else write(_argptr.va_arg!T);
}
}
/* otherwise: don't know how to handle the type */
write(" ");
}
writeln();
}

auto a = A();
SomeStructThatIsNotCopyable s;
a.fun(5, "a", /* by ref: */ s, /* or by pointer: */ );
}


That's not exactly pretty, of course. Both A.fun and the delegate are 
quite complicated. But it might be workable, if run-time variadics are 
acceptable.


I wouldn't be surprised if the problem can be solved more elegantly. But 
I don't see how at the moment.

Re: CTFE Status 2

[via Digitalmars-d]

On Tuesday, 23 May 2017 at 17:26:01 UTC, Stefan Koch wrote:

On Sunday, 21 May 2017 at 14:49:32 UTC, Stefan Koch wrote:


Huh apparently I fixed this issue.
But I cannot rememberer when or how I did it.
This test will now magically work.
This concerns me.


I finally figured out what was going on.
I forgot to activate the -bc-ctfe switch 
A few days of work into the wrong direction *sigh*


Seems like you need to make -bc-ctfe the default in your dmd 
branch :P

Re: why properties don't support +=, -= ... operators?

[via Digitalmars-d]

On Tuesday, 23 May 2017 at 16:43:33 UTC, Stanislav Blinov wrote:

On Tuesday, 23 May 2017 at 16:13:19 UTC, Andrey wrote:
Hello! I am constantly worried about this flaw, why this bug 
still was not resolved: 
https://issues.dlang.org/show_bug.cgi?id=8006

e.g. in Kotlin I can write property like this:

class Example {
var value: Int = 0
set(v) {
field = v
}
get() = field
}

fun main() {
var e = Example()
e.value = 10
e.value += 1
println(e.value)


And it will work!

In D I can write something like this:

class Example {
private int value_; @property {
void value(in int val) {
value_ = val;
}
int value() {
return value_;
}
}
}


That's great, but еhe absence of in-place operators creates 
additional problems sometimes, and using ref I think not a 
good idea, because of inconsistency.


struct Foo
{
private int value_;

void value(int v) { value_ = v; }
ref inout(int) value() inout { return value_; }
}

void main()
{
import std.stdio;
Foo foo;
foo.value += 150;
writeln(foo.value);
}

Which inconsistency do you mean? Not calling a function when 
applying an operator to a property?


The problem is that if you return by ref you loose the ability to 
intercept the setting of the value, i.e. you're no better than 
just making the field public.


AFAIU the OP, he's asking for the following lowering:

e.value += 42;
//   ^
//   v
e.value(e.value() + 42);

However, note that in general such lowering may not always be 
possible or desirable. For example:


e.someContainerProperty ~= new Item();
//   ^
//   v
e.someContainerProperty(e.someContainerProperty() ~ new Item());

Re: DIP 1003 Formal Review

[MysticZach via Digitalmars-d]

On Wednesday, 17 May 2017 at 01:01:29 UTC, MysticZach wrote:
I think there are several issues at hand, and they need to be 
dealt with individually:


1. `body` is a very useful identifier. It would be nice to have 
it available.


2. Contract syntax is too verbose.

3. a. Some people think code looks better with a keyword, e.g. 
`body`, `do`, etc. distinguishing the function from the 
contracts.


3. b. Other people think that such a keyword is unnecessarily 
redundant and does not justify its own existence.


I think the thread will be more productive if the posters 
commit to answering just one of these issues, and reserve other 
issues for other threads. As the DIP in question is directly 
meant to address issue #1, it makes sense to try to solve that 
problem and only that problem here.


I made a related DIP discussing issue 2, contract syntax is too 
verbose. The thread for discussing that one is here:


http://forum.dlang.org/post/tuzdqqpcoguatepgx...@forum.dlang.org

new contract syntax DIP

[MysticZach via Digitalmars-d]

I made a pull request for a new DIP dealing with contract syntax:

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

I write the DIP in response to the discussions for DIP 1003: 
http://forum.dlang.org/thread/wcqebjzdjxldeywlx...@forum.dlang.org


This DIP is not under any kind of formal review yet. I just 
wanted to let people know that it's there.

Re: why properties don't support +=, -= ... operators?

[Andrey via Digitalmars-d]

On Tuesday, 23 May 2017 at 16:43:33 UTC, Stanislav Blinov wrote:

struct Foo
{
private int value_;

void value(int v) { value_ = v; }
ref inout(int) value() inout { return value_; }
}

void main()
{
import std.stdio;
Foo foo;
foo.value += 150;
writeln(foo.value);
}

Which inconsistency do you mean? Not calling a function when 
applying an operator to a property?


yes function not calling when applying an operator.

Re: CTFE Status 2

[Stefan Koch via Digitalmars-d]

On Sunday, 21 May 2017 at 14:49:32 UTC, Stefan Koch wrote:


Huh apparently I fixed this issue.
But I cannot rememberer when or how I did it.
This test will now magically work.
This concerns me.


I finally figured out what was going on.
I forgot to activate the -bc-ctfe switch 
A few days of work into the wrong direction *sigh*

[Issue 17420] std.format.formatObject doesn't work with @safe toString specialization

[via Digitalmars-d-bugs]

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

Jack Stouffer  changed:

   What|Removed |Added

Summary|std.format.formatObject |std.format.formatObject
   |doesn't work with @safe |doesn't work with @safe
   |toString|toString specialization

--

[Issue 17420] New: std.format.formatObject doesn't work with @safe toString

[via Digitalmars-d-bugs]

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

  Issue ID: 17420
   Summary: std.format.formatObject doesn't work with @safe
toString
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

In order to speed up formatting, std.format allows for the following overloads
of toString to be defined


const void toString(scope void delegate(const(char)[]) sink, FormatSpec
fmt);
const void toString(scope void delegate(const(char)[]) sink, string fmt);
const void toString(scope void delegate(const(char)[]) sink);

This allows std format to skip an allocation because the output string of the
object/struct is written directly to the writer.

The problem is that formatObject doesn't work with any of the common function
attributes `pure @safe @nogc nothrow`. If the toString overload is marked with
any of these, hasToString!(YourType) == 0 or it skips your overload and uses
the allocating version.

Either

1. hasToString needs to be modified to recognize these overloads if it's
possible to make the existing format code call safe code
2. Failing that, a couple of new specializations of toString should be defined
that is more idiomatic of Phobos that gives the function an OutputRange
directly, like so

const void toString(O)(O sink, FormatSpec fmt) if (isOutputRange!(O,
char));
const void toString(O)(O sink, string fmt) if (isOutputRange!(O, char));
const void toString(O)(O sink) if (isOutputRange!(O, char));

--

Re: Structure of Arrays vs Array of Structures

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 16:48:31 UTC, Nordlöw wrote:

On Tuesday, 23 May 2017 at 16:46:18 UTC, Nordlöw wrote:

http://forum.dlang.org/post/wvulryummkqtskiwr...@forum.dlang.org


Correction; should be:

https://github.com/nordlow/phobos-next/blob/a324f16515bd1c3c1185ba0482dae2886d811bb1/src/soa.d


What if you instantiate it with a nested struct? What about 
structs that themselves aggregate other structs? What about 
custom operators on such structs?..


As I said earlier, generic solution is not easy. The 
implementation you have is very niche, certainly not "std.".

Re: Structure of Arrays vs Array of Structures

[Nordlöw via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 16:46:18 UTC, Nordlöw wrote:

http://forum.dlang.org/post/wvulryummkqtskiwr...@forum.dlang.org


Correction; should be:

https://github.com/nordlow/phobos-next/blob/a324f16515bd1c3c1185ba0482dae2886d811bb1/src/soa.d

Re: Structure of Arrays vs Array of Structures

[Nordlöw via Digitalmars-d-learn]

On Monday, 15 May 2017 at 19:52:03 UTC, Nordlöw wrote:
soa.d-mixin-143(143,7): Error: variable 
soa.SOA!(S).SOA.container0LU cannot be further field because it 
will change the determined SOA size
soa.d-mixin-143(143,28): Error: variable 
soa.SOA!(S).SOA.container1LU cannot be further field because it 
will change the determined SOA size
soa.d(193,14): Error: template instance soa.SOA!(S) error 
instantiating
soa.d(195,5): Error: static assert  (is(typeof((__error)()) == 
int[])) is false


What's wrong?


When I removed the scope qualifier I went forward with 
`opDispatch` to make it work here


http://forum.dlang.org/post/wvulryummkqtskiwr...@forum.dlang.org

What about adding this little D-magic to std.typecons?

Re: why properties don't support +=, -= ... operators?

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 23 May 2017 at 16:13:19 UTC, Andrey wrote:
Hello! I am constantly worried about this flaw, why this bug 
still was not resolved: 
https://issues.dlang.org/show_bug.cgi?id=8006

e.g. in Kotlin I can write property like this:

class Example {
var value: Int = 0
set(v) {
field = v
}
get() = field
}

fun main() {
var e = Example()
e.value = 10
e.value += 1
println(e.value)


And it will work!

In D I can write something like this:

class Example {
private int value_; @property {
void value(in int val) {
value_ = val;
}
int value() {
return value_;
}
}
}


That's great, but еhe absence of in-place operators creates 
additional problems sometimes, and using ref I think not a good 
idea, because of inconsistency.


struct Foo
{
private int value_;

void value(int v) { value_ = v; }
ref inout(int) value() inout { return value_; }
}

void main()
{
import std.stdio;
Foo foo;
foo.value += 150;
writeln(foo.value);
}

Which inconsistency do you mean? Not calling a function when 
applying an operator to a property?

Re: templatized delegate

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 11:45:13 UTC, Alex wrote:

On Tuesday, 23 May 2017 at 11:05:09 UTC, Stanislav Blinov wrote:

void variadic(Args...)(auto ref Args args) { /* ... */ }

This infers whether you pass lvalues or rvalues. If passing 
further down the chain of such calls is needed, one can use 
std.functional : fowrard :


yes...



void variadic(Args...)(auto ref Args args) {
import std.functional : forward;
doStuff(forward!args);
}

void doStuff(Args...)(auto ref Args args) {
/* ... */
}

'forward' aliases ref arguments (i.e. passed lvalues) and 
moves value arguments (i.e. passed rvalues).


If a value is not copyable, it may be move-able (check the 
docs though, it may not be that either).


void fun(Args...)(auto ref Args args) { /*...*/ }


yes...


import std.algorithm : move;

auto a = NonCopyable(42);

fun(move(a));
// or:
func(NonCopyable(42));


the problem, that I have is, that I would like to use the 
templated approach, but I don't have the function, but only a 
delegate, so:


template(T, U...)
{
void delegate(ref T neededInput, ref U ignoredInput) dgPtr;
}

Not sure, if this is possible to handle at all...


Ah, now I think I get it. You want to store a single delegate 
that could be called with different sets of arguments? No, you 
can't do that: you need an actual delegate instance, and for 
that, you need to know the signature, at least when instantiating 
C.

[Issue 17417] Deprecate signed integer promotions in bitwise operations

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

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

--- Comment #5 from Andrei Alexandrescu  ---
This is core behavior that we don't plan to change. Value Range Propagation is
the way to avoid casts back and forth. Feel free to submit issues related to
it, thanks.

--

why properties don't support +=, -= ... operators?

[Andrey via Digitalmars-d]

Hello! I am constantly worried about this flaw, why this bug 
still was not resolved: 
https://issues.dlang.org/show_bug.cgi?id=8006

e.g. in Kotlin I can write property like this:

class Example {
var value: Int = 0
set(v) {
field = v
}
get() = field
}

fun main() {
var e = Example()
e.value = 10
e.value += 1
println(e.value)


And it will work!

In D I can write something like this:

class Example {
private int value_; @property {
void value(in int val) {
value_ = val;
}
int value() {
return value_;
}
}
}


That's great, but еhe absence of in-place operators creates 
additional problems sometimes, and using ref I think not a good 
idea, because of inconsistency.

Re: Generating checked integral operations [WAS: Trip notes from Israel]

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 23 May 2017 at 15:43:24 UTC, Andrei Alexandrescu 
wrote:

On 05/23/2017 11:37 AM, Stefan Koch wrote:


The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3


That call enters a different overload:

pragma(inline, true)
uint mulu(uint x, uint y, ref bool overflow)
{
ulong r = ulong(x) * ulong(y);
if (r > uint.max)
overflow = true;
return cast(uint)r;
}

which is of efficiency comparable with code using seto. I'm not 
too worried about that. https://goo.gl/eRXUpr is of interest.



Andrei


Well 
Since core.checkedint is in druntime, we _could_ detected the 
checking operations and generate better code for them.

But right now, I am convinced it is worth the effort.

Re: Trip notes from Israel

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 23 May 2017 at 15:37:39 UTC, Stefan Koch wrote:

The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3


The jbe (jump-below-equal)
does check the overflow flag (and redundantly the zero-flag) here
and sets the bool which represents overflow to one.

Generating checked integral operations [WAS: Trip notes from Israel]

[Andrei Alexandrescu via Digitalmars-d-announce]

On 05/23/2017 11:37 AM, Stefan Koch wrote:


The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3 


That call enters a different overload:

pragma(inline, true)
uint mulu(uint x, uint y, ref bool overflow)
{
ulong r = ulong(x) * ulong(y);
if (r > uint.max)
overflow = true;
return cast(uint)r;
}

which is of efficiency comparable with code using seto. I'm not too 
worried about that. https://goo.gl/eRXUpr is of interest.



Andrei

Re: Trip notes from Israel

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 23 May 2017 at 15:19:39 UTC, Andrei Alexandrescu 
wrote:

On 05/23/2017 09:42 AM, Stefan Koch wrote:
On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu 
wrote:

On 5/22/17 4:51 PM, Johan Engelen wrote:

[...]


Thanks! Yes, seto is what I thought of - one way or another, 
it gets down to using a bit of machine-specific code to get 
there. I'll note that dmd does not generate seto (why?): 
https://goo.gl/nRjNMy. -- Andrei


it does this
overflow_flag = 0
op
if (overflowed)
{
   overflow_flag = 1;
}


Where did you see this pattern? Couldn't find it anywhere in 
core.checkedint. And how is "overflowed" tested?



this can in some circumstances be faster then using seto!
If the inliner does a good enough job :)


The code in core.checkedint is conservative:

pragma(inline, true)
ulong mulu(ulong x, ulong y, ref bool overflow)
{
ulong r = x * y;
if (x && (r / x) != y)
overflow = true;
return r;
}

The compiler is supposed to detect the pattern and generate 
optimal code.



Andrei


That code is written nowhere.
It was my hand translation of the asm.
(And it was wrong)

The compiler does indeed seem to optimize the code somewhat.
Although the generated asm still looks wired.
http://asm.dlang.org/#compilers:!((compiler:dmd_nightly,options:'-dip25+-O+-release+-inline+-m32',source:'import+core.checkedint%3B%0A%0Aalias+T+%3D+ulong%3B%0Aextern+(C)+T+foo(uint+x,+uint+y,+ref+bool+overflow)%0A%7B%0A+++return+mulu(x,+y,+overflow)%3B%0A%7D%0A')),filterAsm:(binary:!t,intel:!t),version:3

Runtime?

[Wulfklaue via Digitalmars-d]

A quick question. After watching the DLang 2017 conference, there 
was mention about the runtime optimizing that is going on. Will 
this have a impact on the default memory usage (on small projects 
)?

[Issue 17417] Deprecate signed integer promotions in bitwise operations

[via Digitalmars-d-bugs]

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

--- Comment #4 from anonymous4  ---
I think it's usually used with int, in which case there will be no promotion.
Another thing I can think of is cast(ubyte)(short>>8) which would be a bit more
difficult to check that sign extension doesn't affect the result if we would
want to allow it.

--

Re: DMD VS2017 Support

[via Digitalmars-d]

On Monday, 22 May 2017 at 21:08:02 UTC, Jolly James wrote:
On Monday, 22 May 2017 at 07:28:23 UTC, Vladimir Panteleev 
wrote:

On Sunday, 21 May 2017 at 22:47:44 UTC, Jolly James wrote:

On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote:
Please note that the next dmd installer will also detect 
VS2017 and setup directories correctly in sc.ini: 
https://github.com/dlang/installer/pull/227


I really like this philosophy:
"It does not work, a fix is available, but it won't be rolled 
out (for now). Who cares about those who cannot use the 
broken software?"


Please don't antagonize volunteer contributors who are 
actually creating and improving things. We have a release 
process for a reason, we can't ship every single change 
immediately. If you require a solution urgently, use a 
workaround or build it from source yourself.


My message was neither addressed directly to anybody of the 
volunteer contributors (I have a huge respect of them and their 
great work), nor to anyone at the D Foundation directly. I just 
wanted to critize the whole release cycle stuff itself.


I mean, if for any circumstance, e.g. like the VS2017 thing 
(which did not suddenly appear from one day to another anyway), 
the whole software cannot be used without larger fiddling (in 
this case: setting up NSIS + plugins), it seems quite strange 
to not simply update the installer, which would be a work for a 
few minutes - and after that everybody would be happy.
But to be honest, I don't think that this is a problem of D. 
More or less, this is something that appears everywhere in the 
world of open-source. Here it annoys and chases away users, in 
the corporate sector you could not do so, as this would cause 
the company's ruin.


We already have nightly builds for all platforms supported by dmd 
[0]. We just need a nightly build of the installer, in addition 
to the 7zip archive for Windows. So I'd say we're already doing 
much better than 1-2 years ago.


[0]: http://nightlies.dlang.org/dmd-master-2017-05-23/

[Issue 16527] extern( C++ ) Win64 build - return struct by value is broken

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   Keywords||C++
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13207

--

[Issue 13207] Wrong code for 'extern' C/C++ function returning struct

[via Digitalmars-d-bugs]

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16527

--

Re: How to get rid of const / immutable poisoning (and I didn't even want to use them...)

[Kagamin via Digitalmars-d-learn]

https://dpaste.dzfl.pl/74d67cfca3e8

Re: Idea: Reverse Type Inference

[via Digitalmars-d]

On Monday, 22 May 2017 at 13:39:46 UTC, Timon Gehr wrote:

On 22.05.2017 12:13, Sebastiaan Koppe wrote:
I work with Scala professionally. I often feel its type 
inference for
generics/templates is better than D's; as long as it can find 
a type
_anywhere_ it will use that, no matter where it needs to pull 
it from.


Over the past weeks I have been noticing a specific case where 
it
happens. I call it reverse type inference, simply because it 
goes

against the normal evaluation order.

While it is only syntactic sugar,


(It's not.)


I think it would be nice to have in D
and I want to know what you guys think about it.

Some examples:

---

T convert(T)(string s) { ... }

auto dec = "1234".convert!int;   // normal
int dec = "1234".convert;// T of convert is inferred 
due to type

declaration of dec

int square(int t) { ... }

auto a = "1234".convert.square;  // since square accepts int, 
T of

convert is inferred to be int

---

p.s. I am not asking anyone to build it. I just want to have 
the idea
out there. And if time allows I might take a stab at 
implementing it.


I'm in favour. Note that this already happens in some 
circumstances, e.g. the parameter type of the delegate is 
inferred here from the expected type:


int delegate(int) dg = x=>x;

I suspect your enhancement might actually be easy to implement 
by reusing the same mechanism in the compiler. (I.e. defer the 
template instantiation if forward inference is incomplete, and 
then deduce the remaining template arguments in "matchType".)



Another annoying case:

alias Fun(A,B) = B delegate(A);

B apply(A,B)(Fun!(A,B) f, A a){ return f(a); }

void main(){
apply(x=>x,2); // error
}


Interesting. BTW, what do you think about this feature being 
extended to implicit template instantiations a la Rust: 
https://doc.rust-lang.org/book/generics.html#resolving-ambiguities ?


In Kotlin they have a related feature called smart casts:
https://kotlinlang.org/docs/reference/typecasts.html
(also briefly shown here 
https://www.youtube.com/watch?v=X1RVYt2QKQE=1569s)


Which of course is a subset of the more general area of control 
flow based type analysis. Typescript is good example of bringing 
those things to the JS world: 
https://www.youtube.com/watch?v=d1f6VBmWg6o=39m39s

https://blog.mariusschulz.com/2016/09/30/typescript-2-0-control-flow-based-type-analysis

Re: Which editor to use for editing DDOCs?

[bachmeier via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 07:40:21 UTC, biocyberman wrote:

Adding DDOC support for D Mode require some more work 
obviously. I will see if I can make some changes to that. For 
the time being, I would like to know which editors people are 
using. Or is it a plain black and white editor ?


I use Emacs and Geany.

[Issue 17417] Deprecate signed integer promotions in bitwise operations

[via Digitalmars-d-bugs]

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

--- Comment #3 from uplink.co...@googlemail.com ---
(In reply to anonymous4 from comment #2)
> Promotion in bitwise operators makes better sense for unsigned integers, but
> doesn't make much sense for signed integers, bitwise operators are supposed
> to act on bit arrays, which signed integers are not. After deprecation the
> compiler should give an error for signed integer promotions in bitwise
> operators.

There is precedent for for bitwise operations on singed integers as well, such
as right/left shifts.
To save division cost

--

[Issue 17417] Deprecate signed integer promotions in bitwise operations

[via Digitalmars-d-bugs]

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

--- Comment #2 from anonymous4  ---
Promotion in bitwise operators makes better sense for unsigned integers, but
doesn't make much sense for signed integers, bitwise operators are supposed to
act on bit arrays, which signed integers are not. After deprecation the
compiler should give an error for signed integer promotions in bitwise
operators.

--

Re: Which editor to use for editing DDOCs?

[bauss via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 07:40:21 UTC, biocyberman wrote:

On Monday, 22 May 2017 at 15:33:36 UTC, Russel Winder wrote:

[...]


Adding DDOC support for D Mode require some more work 
obviously. I will see if I can make some changes to that. For 
the time being, I would like to know which editors people are 
using. Or is it a plain black and white editor ?


I just use Atom.

Re: Trip notes from Israel

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 23 May 2017 at 13:27:42 UTC, Andrei Alexandrescu 
wrote:

On 5/22/17 4:51 PM, Johan Engelen wrote:
On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu 
wrote:

[...]


A fun read!

"(Late at night, I double checked. Mozilla’s CheckedInt is 
just as bad as I remembered. They do a division to test for 
multiplication overflow. Come on, put a line of assembler in 
there! Portability is worth a price, just not any price.)"


Shocked: do you use assembly in Checked and cripple the 
optimizer?!?!
Luckily, no. But LDC and GDC do create the `seto` instruction 
I think you were hinting at:

https://godbolt.org/g/0jUhgs

(LDC doesn't do as good as it could, 
https://github.com/ldc-developers/ldc/issues/2131)


Thanks! Yes, seto is what I thought of - one way or another, it 
gets down to using a bit of machine-specific code to get there. 
I'll note that dmd does not generate seto (why?): 
https://goo.gl/nRjNMy. -- Andrei


it does this
overflow_flag = 0
op
if (overflowed)
{
  overflow_flag = 1;
}

this can in some circumstances be faster then using seto!
If the inliner does a good enough job :)

Re: Trip notes from Israel

[Andrei Alexandrescu via Digitalmars-d-announce]

On 5/22/17 4:51 PM, Johan Engelen wrote:

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ 
-- Andrei


A fun read!

"(Late at night, I double checked. Mozilla’s CheckedInt is just as bad 
as I remembered. They do a division to test for multiplication overflow. 
Come on, put a line of assembler in there! Portability is worth a price, 
just not any price.)"


Shocked: do you use assembly in Checked and cripple the optimizer?!?!
Luckily, no. But LDC and GDC do create the `seto` instruction I think 
you were hinting at:

https://godbolt.org/g/0jUhgs

(LDC doesn't do as good as it could, 
https://github.com/ldc-developers/ldc/issues/2131)


Thanks! Yes, seto is what I thought of - one way or another, it gets 
down to using a bit of machine-specific code to get there. I'll note 
that dmd does not generate seto (why?): https://goo.gl/nRjNMy. -- Andrei

Re: Trip notes from Israel

[Swoorup Joshi via Digitalmars-d-announce]

On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:

http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/ -- 
Andrei


Interesting read. You're my brother from another mother. :)

Re: templatized delegate

[Alex via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 11:05:09 UTC, Stanislav Blinov wrote:

void variadic(Args...)(auto ref Args args) { /* ... */ }

This infers whether you pass lvalues or rvalues. If passing 
further down the chain of such calls is needed, one can use 
std.functional : fowrard :


yes...



void variadic(Args...)(auto ref Args args) {
import std.functional : forward;
doStuff(forward!args);
}

void doStuff(Args...)(auto ref Args args) {
/* ... */
}

'forward' aliases ref arguments (i.e. passed lvalues) and moves 
value arguments (i.e. passed rvalues).


If a value is not copyable, it may be move-able (check the docs 
though, it may not be that either).


void fun(Args...)(auto ref Args args) { /*...*/ }


yes...


import std.algorithm : move;

auto a = NonCopyable(42);

fun(move(a));
// or:
func(NonCopyable(42));


the problem, that I have is, that I would like to use the 
templated approach, but I don't have the function, but only a 
delegate, so:


template(T, U...)
{
void delegate(ref T neededInput, ref U ignoredInput) dgPtr;
}

Not sure, if this is possible to handle at all...

Re: templatized delegate

[Alex via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 10:42:54 UTC, Nicholas Wilson wrote:

On Tuesday, 23 May 2017 at 10:30:56 UTC, Alex wrote:

On Monday, 22 May 2017 at 21:44:17 UTC, ag0aep6g wrote:
With that kind of variadics, you're not dealing with a 
template. A (run-time) variadic delegate is an actual 
delegate, i.e. a value that can be passed around. But the 
variadic stuff is a bit weird to use, and probably affects 
performance.


By the way, I'm not even sure, if variadics work in my case. I 
have a strange struct of a random generator, which cannot be 
copied, and I have no idea how to pass it to a variadic 
function:


import std.stdio;
import mir.random;

void main()
{
Random rndGen = Random(unpredictableSeed);
fun(rndGen);
}

void fun(...)
{

}

Yields "... is not copyable because it is annotated with 
@disable" :)


Random is copy @disabled to prevent incorrect use.


Yes, I'm aware of this...

You need to pass it by ref or pointer. I dont know if you can 
pass variables as ref to a variadic, but you should be able to 
pass it by address.

fun();


No, you can't pass a ref into a variadic... if the test above is 
written correct.
And no, I can't pass it by adress, as I don't know apriori, 
whether the very parameter which gets the random generator is 
already a part of the variadic parameters, or a well defined ref 
parameter.
Especially, there are some functions for both cases. While the 
argument list remains the same, the acceptor part is meant to 
work with it somehow.
The other way around would be, to manipulate the argument list, 
which is shared...

Re: templatized delegate

[9il via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 10:30:56 UTC, Alex wrote:

On Monday, 22 May 2017 at 21:44:17 UTC, ag0aep6g wrote:
With that kind of variadics, you're not dealing with a 
template. A (run-time) variadic delegate is an actual 
delegate, i.e. a value that can be passed around. But the 
variadic stuff is a bit weird to use, and probably affects 
performance.


By the way, I'm not even sure, if variadics work in my case. I 
have a strange struct of a random generator, which cannot be 
copied, and I have no idea how to pass it to a variadic 
function:


import std.stdio;
import mir.random;

void main()
{
Random rndGen = Random(unpredictableSeed);
fun(rndGen);
}

void fun(...)
{

}

Yields "... is not copyable because it is annotated with 
@disable" :)


1. Pass its pointer
2. Use variadic template with auto ref:

```
void foo(T...)(auto ref T tup)
{
}
```

Re: templatized delegate

[Stanislav Blinov via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 10:42:54 UTC, Nicholas Wilson wrote:

On Tuesday, 23 May 2017 at 10:30:56 UTC, Alex wrote:

On Monday, 22 May 2017 at 21:44:17 UTC, ag0aep6g wrote:
With that kind of variadics, you're not dealing with a 
template. A (run-time) variadic delegate is an actual 
delegate, i.e. a value that can be passed around. But the 
variadic stuff is a bit weird to use, and probably affects 
performance.


By the way, I'm not even sure, if variadics work in my case. I 
have a strange struct of a random generator, which cannot be 
copied, and I have no idea how to pass it to a variadic 
function:


import std.stdio;
import mir.random;

void main()
{
Random rndGen = Random(unpredictableSeed);
fun(rndGen);
}

void fun(...)
{

}

Yields "... is not copyable because it is annotated with 
@disable" :)


Random is copy @disabled to prevent incorrect use.
You need to pass it by ref or pointer. I dont know if you can 
pass variables as ref to a variadic, but you should be able to 
pass it by address.

fun();


void variadic(Args...)(auto ref Args args) { /* ... */ }

This infers whether you pass lvalues or rvalues. If passing 
further down the chain of such calls is needed, one can use 
std.functional : fowrard :


void variadic(Args...)(auto ref Args args) {
import std.functional : forward;
doStuff(forward!args);
}

void doStuff(Args...)(auto ref Args args) {
/* ... */
}

'forward' aliases ref arguments (i.e. passed lvalues) and moves 
value arguments (i.e. passed rvalues).


If a value is not copyable, it may be move-able (check the docs 
though, it may not be that either).


void fun(Args...)(auto ref Args args) { /*...*/ }

import std.algorithm : move;

auto a = NonCopyable(42);

fun(move(a));
// or:
func(NonCopyable(42));

Re: templatized delegate

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 23 May 2017 at 10:30:56 UTC, Alex wrote:

On Monday, 22 May 2017 at 21:44:17 UTC, ag0aep6g wrote:
With that kind of variadics, you're not dealing with a 
template. A (run-time) variadic delegate is an actual 
delegate, i.e. a value that can be passed around. But the 
variadic stuff is a bit weird to use, and probably affects 
performance.


By the way, I'm not even sure, if variadics work in my case. I 
have a strange struct of a random generator, which cannot be 
copied, and I have no idea how to pass it to a variadic 
function:


import std.stdio;
import mir.random;

void main()
{
Random rndGen = Random(unpredictableSeed);
fun(rndGen);
}

void fun(...)
{

}

Yields "... is not copyable because it is annotated with 
@disable" :)


Random is copy @disabled to prevent incorrect use.
You need to pass it by ref or pointer. I dont know if you can 
pass variables as ref to a variadic, but you should be able to 
pass it by address.

fun();

Re: templatized delegate

[Alex via Digitalmars-d-learn]

On Monday, 22 May 2017 at 21:44:17 UTC, ag0aep6g wrote:
With that kind of variadics, you're not dealing with a 
template. A (run-time) variadic delegate is an actual delegate, 
i.e. a value that can be passed around. But the variadic stuff 
is a bit weird to use, and probably affects performance.


By the way, I'm not even sure, if variadics work in my case. I 
have a strange struct of a random generator, which cannot be 
copied, and I have no idea how to pass it to a variadic function:


import std.stdio;
import mir.random;

void main()
{
Random rndGen = Random(unpredictableSeed);
fun(rndGen);
}

void fun(...)
{

}

Yields "... is not copyable because it is annotated with 
@disable" :)

Re: Which editor to use for editing DDOCs?

[Russel Winder via Digitalmars-d-learn]

On Tue, 2017-05-23 at 07:40 +, biocyberman via Digitalmars-d-learn
wrote:
> 
[…]
> Adding DDOC support for D Mode require some more work obviously. 
> I will see if I can make some changes to that. For the time 
> being, I would like to know which editors people are using. Or is 
> it a plain black and white editor ?

Until IntelliJ IDEA and/or CLion works for D, Emacs is my only D
editor.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: Trip notes from Israel

[kinke via Digitalmars-d-announce]

On Tuesday, 23 May 2017 at 08:18:26 UTC, Iain Buclaw wrote:
If you want a hint (though it's not my place to say), LLVM I'm 
told is a reasonably OK compiler, and any reasonably OK 
compiler should come with overflow intrinsics - try using them 
directly.


The intrinsics are exposed by LDC's druntime, they just need to 
be made use of:

https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/intrinsics.di#L446-L468

Re: Idea: Reverse Type Inference

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 22 May 2017 at 10:13:02 UTC, Sebastiaan Koppe wrote:
Over the past weeks I have been noticing a specific case where 
it happens. I call it reverse type inference, simply because it 
goes against the normal evaluation order.


I think what you want, in the general sense, is basically 
overloading based on return-type. Which I think is a very useful 
and cool feature.


But D moste likely follows  C++ by doing resolution bottom-up 
(starting from the leaves of the AST).


For the requested feature you need to do resolution top-down 
(which I believe Ada does).


The downside of this is when you hit ambiguities, thanks to 
implicit conversion/coercion (which I think is mostly a 
mal-feature and a source for bugs).


One solution to this is to give preference to the match that use 
the fewest implicit conversions.


But I think the better solution is to:

1. remove implicit type conversion

2. add a more compact notation for indicating desired type so 
that you can call the desired function without using the return 
value. (i.e. "f(x):int" to request the version of f(x) that 
returns int)


You might hack together a solution just for templates, but it 
makes the language even less orthogonal than it is. So I think D 
is better off doing it in a manner that is consistent and avoids 
more special cases.

Re: checkedint call removal

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 23 May 2017 at 08:41:12 UTC, Ola Fosheim Grøstad 
wrote:
But in C++/D etc "predicate" usually is just used to refer to a 
boolean pure function in the language. Which is reasonable 
since there is no support for propositional or predicate logic. 
A D assert is only evaluated when we know the actual boolean 
value, which is sound.


As an example, if D had support for propositions we would be able 
to instantiate templates with boolean parameters using 
expressions like:


f(int x){
   … sometemplate!(x*x >= 0) …
}

with x being unknown at compile time.

Re: checkedint call removal

[Ola Fosheim Grøstad via Digitalmars-d]

Just clearing up an old post that bugs me:

On Friday, 1 August 2014 at 10:24:26 UTC, Ola Fosheim Grøstad 
wrote:

An assert does not take a predicate.


That was true, as far as D asserts go... but this is also 
confusing since "predicate" and "assert" can mean different 
things in different contexts and what I wrote here was a really 
bad way of putting it:



bool test(bool x) {return x || !x} // predicate

test(x) for all x in {true,false} // proposition


The terminology used above is likely to confuse an unsuspecting 
reader, so to make it more clear:


Proposition, as in propositional logic (zeroth order logic): 
Logic statements that allows us to reason about individual 
boolean constants without necessarily knowing their actual value. 
I.e. we list each one "test(true) && test(false)", 
"test(X)&(!X)" or just "test(X)" etc.


Predictate, as in predicate logic (first order logic): statements 
that extends propositions by expressing possibly infinite sets of 
values (e.g.  "f(x) holds for all integers lager than 3" or 
"there exists at least one integer x for which f(x) evaluates to 
true"). In essence it allows you to write an and-expression or 
or-expression with an infinite number of terms.


But in C++/D etc "predicate" usually is just used to refer to a 
boolean pure function in the language. Which is reasonable since 
there is no support for propositional or predicate logic. A D 
assert is only evaluated when we know the actual boolean value, 
which is sound.


So what I meant in this thread is that a compiler should not 
conclude that an assert holds as if it was a proposition. I.e. 
turn run-time assertions into compile-time assumptions.


In the context of verification a predicate, in the sense of 
having for-all or there-exists quantifiers, can be tricky since 
we may actually run into a statement that may always be true, but 
for which no known proof exists. (And there we enter the whole 
domain of the halting problem etc, which essentially boils down 
to there being more problems than proofs.)


Terminology is such a nuisance...

Re: Trip notes from Israel

[Iain Buclaw via Digitalmars-d-announce]

On 22 May 2017 at 22:51, Johan Engelen via Digitalmars-d-announce
 wrote:
> On Monday, 22 May 2017 at 15:05:24 UTC, Andrei Alexandrescu wrote:
>>
>> http://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/
>> -- Andrei
>
>
> A fun read!
>
> "(Late at night, I double checked. Mozilla’s CheckedInt is just as bad as I
> remembered. They do a division to test for multiplication overflow. Come on,
> put a line of assembler in there! Portability is worth a price, just not any
> price.)"
>
> Shocked: do you use assembly in Checked and cripple the optimizer?!?!
> Luckily, no. But LDC and GDC do create the `seto` instruction I think you
> were hinting at:
> https://godbolt.org/g/0jUhgs
>

So for LDC to be as good as GDC, you need to need to compile with
-enable-ldc-amazing-feature-cross-module-inlining?

> (LDC doesn't do as good as it could,
> https://github.com/ldc-developers/ldc/issues/2131)
>

If you want a hint (though it's not my place to say), LLVM I'm told is
a reasonably OK compiler, and any reasonably OK compiler should come
with overflow intrinsics - try using them directly.

(Turning off mild morning sarcasm).

Iain.

Re: Which editor to use for editing DDOCs?

[biocyberman via Digitalmars-d-learn]

On Monday, 22 May 2017 at 15:33:36 UTC, Russel Winder wrote:
On Mon, 2017-05-22 at 14:14 +, biocyberman via 
Digitalmars-d-learn wrote:
Which one do you use? I am using Linux and Emacs for editing 
other D source file. But the DDOC syntaxes and keywords are 
not well high-lighted.


There has been no work on handling DDOC comments specially in 
the Emacs D Mode as far as I know. There is some attempt to do 
things for Doxygen, but I am not sure how successful that is as 
I am not using it.


It is not clear to me that all D's comment mechanisms are 
handled as they should be. It should be possible, albeit 
non-trivial I suspect, to add support for all the comment forms 
and the DDOC macro markup.


The question does anyone have the energy to get stuck into the 
E-Lisp to achieve the goal – and write the tests to prove it?


Adding DDOC support for D Mode require some more work obviously. 
I will see if I can make some changes to that. For the time 
being, I would like to know which editors people are using. Or is 
it a plain black and white editor ?