[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #8 from Manu --- Non-static foreach doesn't seem to be the same. There are new errors with old usage of foreach instructing to use static foreach instead. And it definitely worked at top level. I was using it to

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 14:34:01 UTC, ag0aep6g wrote: On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote: One issue is that postblit constructors fundamentally don't work with const. The problem is that a postblit constructor works by copying the object and _then_ mutating it,

Re: Deprecating this(this)

On Sunday, April 01, 2018 10:31:46 Andrei Alexandrescu via Digitalmars-d wrote: > On 4/1/18 9:37 AM, Jonathan M Davis wrote: > > One issue is that postblit constructors fundamentally don't work with > > const. > Actually they do... How so? In the postblit, you're dealing with a copy of an object

Re: Fast GC allocation of many small objects

On Sunday, 1 April 2018 at 10:59:55 UTC, Alexandru jercaianu wrote: On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote: On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu wrote: Hello, You can try the following: struct Node { char[64] arr; }

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #7 from Ketmar Dark --- `foreach` never worked at the top level. and non-static forach works *exactly* the same as before. you are clearly has a very different compiler than the rest of us. --

Re: Deprecating this(this)

On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote: On 3/31/18 8:32 PM, H. S. Teoh wrote: [...] What exactly is it about this(this) that blocks us from doing that? See the updated docs. Too many bugs in design and implementation. Removing this(this) is going to be a huge breaking change far

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #9 from Ketmar Dark --- >Non-static foreach doesn't seem to be the same. example, please. *nothing* was changed in old foreach. >And it definitely worked at top level. example, please. i have several different

Re: __has_side_effects

On Sunday, April 01, 2018 06:23:40 Andrei Alexandrescu via Digitalmars-d wrote: > On 4/1/18 2:22 AM, Uknown wrote: > > On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote: > >> [...] > >> > >> I knew I was missing something. Fixed it, thanks > >> > >> https://run.dlang.io/is/tZeZrP > > > >

Global hotkey with GTK based application under Windows

Hello! I implement a GTK-D based application for Windows and Linux. In case of Linux there isn't any problem, I use binding[1] for libkeybinder. In case of Windows I can't find convinient way to implement global shortcuts. There is a way to get it done is use of WinAPI but it's not convinient

Re: newCTFE Status March 2018

On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote: 85 to 90% maybe. I expect that there will many bugs which were hidden by newCTFE not supporting classes, which will now be out in the open and have to be dealt with. Also the code is in need of cleanup before I would release it for

Re: does it scale to have 1 person approve of all phobos additions?

FWIW, my dmd bug fix PR is getting languish-y. https://github.com/dlang/dmd/pull/8051 Ideally a good bug fix shouldn't sit around for a week. Why I'd call this one good: * in addition to reported bug (struct initializer incorrectly parsed as function literal), a read of the code

[Issue 18652] hashOf example doesn't compile

https://issues.dlang.org/show_bug.cgi?id=18652 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote: So, I think that the only large-scale benefit thet exists for pure and really can exist for pure is the fact that you know that the function doesn't access global, mutable state. Everything else it does is just gravy and too

Re: Deprecating this(this)

On Sunday, April 01, 2018 14:55:07 ag0aep6g via Digitalmars-d wrote: > On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote: > > On 3/31/18 8:32 PM, H. S. Teoh wrote: > [...] > > >> What exactly is it about this(this) that blocks us from doing that? > > > > See the updated docs. Too many bugs in

Re: __has_side_effects

On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu wrote: On 4/1/18 2:22 AM, Uknown wrote: [...] That's a great initiative, and a worthy trait for the stdlib. I think you'd have an easier time if you reasoned from the other end. A function is strongly pure if all of the following

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

On 2018-03-30 08:53, Dmitry Olshansky wrote: With the frame of mind prevalent in our Industry I really want to have compiler includibg codegen as a bunch of library components. Then there is no problem innovating while people argue over things “allowed” for a compiler, or a linker, or a

Re: CTFE ^^ (pow)

Been meaning to respond to this for some time now, finally got around to it. :) On Monday, 19 March 2018 at 00:59:45 UTC, Manu wrote: On 18 March 2018 at 17:28, Joakim via Digitalmars-d wrote: Perhaps the community simply has different priorities than you? For

Optional parameters?

I currently have a situation where I want to have a function that accepts a parameter optionally. I thought maybe Nullable!int might work: void foo(Nullable!int) {} void main() { foo(1); // error int x; foo(x); // error } Apparently, I have to manually wrap an int to get it to pass.

Re: __has_side_effects

On Sunday, 1 April 2018 at 14:33:14 UTC, Andrei Alexandrescu wrote: On 4/1/18 9:39 AM, Uknown wrote: On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu wrote: On 4/1/18 2:22 AM, Uknown wrote: [...] Terrific, thanks!! Created the PR: https://github.com/dlang/phobos/pull/6403

Re: std.variant Is Everything Cool About D

On Saturday, 31 March 2018 at 17:36:30 UTC, Pjotr Prins wrote: Great blog. Thanks. Thank you, glad you liked it.

dub / libs / rebuild not triggered

Hi, I have the following line in my dub.json file: "libs-windows-x86_64": ["user32", "kernel32", "gdi32", "b2d_playground"] b2d_playground is a C based .lib file. If this lib is updated and I run: dub build --arch=x86_64 nothing happens. The EXE is not rebuild, taking into accoun the updated

Re: Deprecating this(this)

On 4/1/18 10:59 AM, Nicholas Wilson wrote: On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu wrote: There's a mix of fundamental flaws and bugs. I'll get to the flaws in a second. About the bugs: people have altered their code in various ways to work with the bizarre semantics of

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

On 3/28/18 7:50 AM, Timon Gehr wrote: "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's much easier to relax the spec in the future with

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #6 from Manu --- I used 'foreach', which doesn't work anymore. Since static foreach was added, the non-static one doesn't work the same. static foreach should to all the static stuff that foreach used to do. --

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #10 from Manu --- Remove the 'static' from my OP and you have it. It definitely worked. They flew me to dconf in 2013 and I gave a whole lecture about it. I don't work there anymore, so I don't have the code. I was

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #11 from Ketmar Dark --- module test; foreach(m; __traits(allMembers, test)) { pragma(msg, m); } rdmd --force --compiler=ldc --eval="pragma(msg, __VERSION__);" 2073L rdmd --force --compiler=ldc -c

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #12 from Manu --- I'd love to paste code... But I wrote it in 2012 at a company I don't work at anymore. Think D2.042... I'll see what I can do when I'm not in bed on a phone. But I have no idea what now I can

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #13 from Ketmar Dark --- >Think D2.042 easy deal: http://downloads.dlang.org/releases/2010/ [pts/44:ketmar]:D/_old_dmd% ./dmd2/linux/bin/dmd Digital Mars D Compiler v2.042 Copyright (c) 1999-2010 by Digital Mars

Re: __has_side_effects

On 4/1/18 9:39 AM, Uknown wrote: On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu wrote: On 4/1/18 2:22 AM, Uknown wrote: [...] That's a great initiative, and a worthy trait for the stdlib. I think you'd have an easier time if you reasoned from the other end. A function is

Re: __has_side_effects

On 4/1/18 9:46 AM, Jonathan M Davis wrote: In principle, a function which has const parameters could be treated as strongly pure if it's given immutable arguments I want to give coders leeway to cheat on that. I'll explain later (allocators).

Re: Deprecating this(this)

On 4/1/18 8:55 AM, ag0aep6g wrote: On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote: On 3/31/18 8:32 PM, H. S. Teoh wrote: [...] What exactly is it about this(this) that blocks us from doing that? See the updated docs. Too many bugs in design and implementation. Removing this(this) is

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote: One issue is that postblit constructors fundamentally don't work with const. The problem is that a postblit constructor works by copying the object and _then_ mutating it, and you can't mutate a const object. To cleanly deal with

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 13:37:43 UTC, Jonathan M Davis wrote: One issue is that postblit constructors fundamentally don't work with const. The problem is that a postblit constructor works by copying the object and _then_ mutating it, and you can't mutate a const object. I'm not so sure if

Re: Deprecating this(this)

On 4/1/18 9:37 AM, Jonathan M Davis wrote: One issue is that postblit constructors fundamentally don't work with const. Actually they do...

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu wrote: There's a mix of fundamental flaws and bugs. I'll get to the flaws in a second. About the bugs: people have altered their code in various ways to work with the bizarre semantics of this(this). Now, if we fix various bugs in

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 14:31:24 UTC, Andrei Alexandrescu wrote: Now, if we fix various bugs in this(this) by virtually redefining it, then we'll break a lot of code in a lot of ways. To wit, we fixed a small issue and it already created problems: https://github.com/dlang/dmd/pull/8032.

Re: Optional parameters?

On 2018-04-01 17:54, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. I thought maybe Nullable!int might work: void foo(Nullable!int) {} void main() {    foo(1); // error    int x;    foo(x); // error }

Re: __has_side_effects

On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote: [...] I knew I was missing something. Fixed it, thanks https://run.dlang.io/is/tZeZrP Sorry for the spam, but I also managed to miss `immutable`, `const` and when T has mutable indirections Final version that I'm sure covers all the

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 greenify changed: What|Removed |Added CC||greeen...@gmail.com ---

Re: Deprecating this(this)

On 4/1/18 6:04 AM, Johannes Loher wrote: This seems really sudden, april fool's joke? Not really sure, as there are real problems with this(this)... I'm glad I've sent it yesterday then at least in my time zone :o). This looks sudden but isn't. Eduard and I have been blocked by this problem

Re: auto-decoding

On Sunday, 1 April 2018 at 02:44:32 UTC, Uknown wrote: If you want to stop auto-decoding, you can use std.string.representation like this: import std.string : representation; auto no_decode = some_string.representation; Now no_decode wont be auto-decoded, and you can use it in place of

Re: does it scale to have 1 person approve of all phobos additions?

On Sunday, 1 April 2018 at 08:07:09 UTC, John Belmonte wrote: FWIW, my dmd bug fix PR is getting languish-y. https://github.com/dlang/dmd/pull/8051 Ideally a good bug fix shouldn't sit around for a week. Why I'd call this one good: * in addition to reported bug (struct initializer

Re: __has_side_effects

On 4/1/18 2:22 AM, Uknown wrote: On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote: [...] I knew I was missing something. Fixed it, thanks https://run.dlang.io/is/tZeZrP Sorry for the spam, but I also managed to miss `immutable`, `const` and when T has mutable indirections Final

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote: This seems really sudden, april fool's joke? Not really sure, as there are real problems with this(this)... What I was wondering too. I mean, breaking changes just don't happen to this language. Now there will be, without even an

Re: Deprecating this(this)

On Saturday, 31 March 2018 at 23:38:06 UTC, Andrei Alexandrescu wrote: * immutable and const are very difficult, but we have an attack (assuming copy construction gets taken care of) * pure is difficult How about removing pure, const and immutable?

Re: Deprecating this(this)

On Sunday, April 01, 2018 12:23:29 Per Nordlöw via Digitalmars-d wrote: > On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote: > > Another potential issue is whether any of this does or should > > relate to > > > > https://github.com/dlang/DIPs/pull/109 > > > > and it's solution for

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #3 from Manu --- I barely understood a word of that post. Point is, this used to work... I've been using this for almost 10 years to do a bunch of codegen for stuff in module scope. --

Re: Deprecating this(this)

Am 01.04.2018 um 01:38 schrieb Andrei Alexandrescu: > We need to have a simple recipe on how to define a canonical object. > That would include requirements such as: > > * should work with mutable, const, immutable, and shared > * the right way to define constructor(s) > * the right way to define

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 10:49:22 UTC, bachmeier wrote: On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote: This seems really sudden, april fool's joke? Not really sure, as there are real problems with this(this)... What I was wondering too. I mean, breaking changes just don't

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote: Another potential issue is whether any of this does or should relate to https://github.com/dlang/DIPs/pull/109 and it's solution for hooking into to moves. I'm not at all sure that what happens with that needs to be related to

Re: Fast GC allocation of many small objects

On Saturday, 31 March 2018 at 20:17:26 UTC, Per Nordlöw wrote: On Friday, 30 March 2018 at 23:09:33 UTC, Alexandru Jercaianu wrote: Hello, You can try the following: struct Node { char[64] arr; } enum numNodes = 100_000_000; void[] buf =

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #5 from Ketmar Dark --- [i]>I've been using this for almost 10 years[/i] static foreach? so you really have a time machine, or a specially-crafted compiler version you never gave others?! please, can you show us

[Issue 18652] hashOf example doesn't compile

https://issues.dlang.org/show_bug.cgi?id=18652 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/41eb363d75f38bace0a9a1f8e39bd5805cd98c61 Fix Issue 18652 - hashOf example doesn't compile

Re: Deprecating this(this)

On Sunday, April 01, 2018 11:37:21 Guillaume Piolat via Digitalmars-d wrote: > On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote: > > So, I think that the only large-scale benefit thet exists for > > pure and really can exist for pure is the fact that you know > > that the function

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

On 01.04.2018 19:20, Andrei Alexandrescu wrote: On 3/28/18 7:50 AM, Timon Gehr wrote: "The proposal could be amended to accept mutable ref's depending on the value-judgement balancing these 2 use cases. Sticking with const requires no such value judgement to be made at this time, and it's

Re: newCTFE Status March 2018

On Sunday, 1 April 2018 at 18:32:00 UTC, Stefan Koch wrote: On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote: [...] Oh I was not aware people would try this :) I have fixed the build please pull. Thanks!

Re: __has_side_effects

On Saturday, 31 March 2018 at 20:44:13 UTC, Andrei Alexandrescu wrote: Yah, only strongly pure functions would qualify. Indeed that's easy for the compiler to figure - so I'm thinking pragma(isStronglyPure, expression) would be easy to define. What would be some good uses of this? Andrei

Re: newCTFE Status March 2018

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote: [...] Oh I was not aware people would try this :) I have fixed the build please pull.

Re: newCTFE Status March 2018

On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote: [...] What is going on here is that it tries to build the gccjit backend which is currently in a dysfunctional state. I am currently getting trying to get libgccjit working such that I can make use of it's debug output, while I am

Re: Optional parameters?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: void main() { foo(1); // error int x; foo(x); // error } For the first line, I had the same problem a while ago... https://issues.dlang.org/show_bug.cgi?id=15792

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

[Issue 18702] New: FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

https://issues.dlang.org/show_bug.cgi?id=18702 Issue ID: 18702 Summary: FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404 Product: D

Re: D compiles fast, right? Right??

On Sunday, 1 April 2018 at 02:40:26 UTC, Walter Bright wrote: On 3/30/2018 1:17 PM, Andrei Alexandrescu wrote: Could be faster. It's been a fair amount of time since somebody has done profiling of dmd. It needs to be done. There's probably plenty of low hanging fruit. Speculating about why

DIP Draft Review: ref const(T) should receive r-values

This DIP is a candidate to become DIP 1014. There's already been some discussion about this in the forums and some feedback on the PR, but more Draft Review feedback is needed. The intent of the Draft Review is primarily to find obvious flaws with the DIP, e.g. structural faults, uncovered

[Issue 18703] Ddoc Backticks inside macro dont work.

https://issues.dlang.org/show_bug.cgi?id=18703 Seb changed: What|Removed |Added CC||greensunn...@gmail.com

Re: Optional parameters?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. I thought maybe Nullable!int might work: void foo(Nullable!int) {} void main() { foo(1); // error int x; foo(x); //

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

On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d wrote: > On 01.04.2018 19:20, Andrei Alexandrescu wrote: >> >> On 3/28/18 7:50 AM, Timon Gehr wrote: >>> >>> "The proposal could be amended to accept mutable ref's depending on the >>> value-judgement balancing

Re: DIP Draft Review: ref const(T) should receive r-values

On Monday, 2 April 2018 at 05:09:29 UTC, Mike Parker wrote: On Monday, 2 April 2018 at 05:06:21 UTC, Mike Parker wrote: Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate. https://github.com/dlang/DIPs/pull/109 Sorry everyone. Got my links mixed up.

Re: DIP Draft Review: Hooking D's struct move semantics

On Monday, 2 April 2018 at 05:07:25 UTC, Mike Parker wrote: On Monday, 2 April 2018 at 04:34:03 UTC, Mike Parker wrote: Please keep feedback on the DIP in the PR thread. Thanks in advance to all who participate. https://github.com/dlang/DIPs/pull/111 Sorry everyone. Got my links mixed

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

https://issues.dlang.org/show_bug.cgi?id=18702 Seb changed: What|Removed |Added Keywords||pull CC|

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

https://issues.dlang.org/show_bug.cgi?id=18702 Seb changed: What|Removed |Added Hardware|x86 |All

[Issue 18702] FAQ item "What does D have that C++ doesn't?" comparison link (https://dlang.org/articles/comparison.html) returns 404

https://issues.dlang.org/show_bug.cgi?id=18702 jonath...@gmail.com changed: What|Removed |Added URL||https://dlang.org/articles/

[Issue 17607] not an associative array initializer

https://issues.dlang.org/show_bug.cgi?id=17607 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

[Issue 18703] New: Ddoc Backticks inside macro dont work.

https://issues.dlang.org/show_bug.cgi?id=18703 Issue ID: 18703 Summary: Ddoc Backticks inside macro dont work. Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal

DIP Draft Review: Hooking D's struct move semantics

This DIP is a candidate to become DIP 1014. There has been light feedback already, but there's room for more. Everyone is invited to participate. The intent of the Draft Review is primarily to find obvious flaws with DIP, e.g. structural faults, uncovered bases, lack of clarity, etc.. At

[Issue 18698] static foreach + __traits(allMembers, moduleName)

https://issues.dlang.org/show_bug.cgi?id=18698 --- Comment #15 from Manu --- Okay, I must have had some workaround... I don't remember what exactly, it was some years ago. I probably wrapped it in layers until it worked. Regardless, it should work. My colleague just tried to

Re: Optional parameters?

On Sunday, April 01, 2018 11:54:16 Steven Schveighoffer via Digitalmars-d- learn wrote: > I currently have a situation where I want to have a function that > accepts a parameter optionally. > > I thought maybe Nullable!int might work: > > void foo(Nullable!int) {} > > void main() > { > foo(1);

Re: Optional parameters?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. I thought maybe Nullable!int might work: void foo(Nullable!int) {} void main() { foo(1); // error int x; foo(x); //

Re: Optional parameters?

On Sunday, April 01, 2018 22:37:17 Boris-Barboris via Digitalmars-d-learn wrote: > On Sunday, 1 April 2018 at 22:25:45 UTC, Jonathan M Davis wrote: > > How would a pointer help? Instead of doing > > > > foo(nullable(42)) > > > > he'd have to do > > > > foo(new int(42)) > > > > which is just one

Re: Optional parameters?

On Sunday, April 01, 2018 22:34:16 Seb via Digitalmars-d-learn wrote: > On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer > > wrote: > > I currently have a situation where I want to have a function > > that accepts a parameter optionally. > > > > I thought maybe Nullable!int might

Re: Optional parameters?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. why not simply use function overloading?

Re: Deprecating this(this)

On Sunday, 1 April 2018 at 17:08:37 UTC, Andrei Alexandrescu wrote: On 4/1/18 10:59 AM, Nicholas Wilson wrote: for 1. consider immutable foo = ...; immutable bar = foo; to be immutable foo = ...; immutable bar = () {mutable _ = bitcopy(foo); _.__postblit(); return _;}(); Negative. The

Re: Optional parameters?

On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer wrote: I currently have a situation where I want to have a function that accepts a parameter optionally. I would simply use a pointer for this. Fighting D grammar seems too much of a hassle for such simple task.

Re: Optional parameters?

On Sunday, April 01, 2018 22:06:57 Boris-Barboris via Digitalmars-d-learn wrote: > On Sunday, 1 April 2018 at 15:54:16 UTC, Steven Schveighoffer > > wrote: > > I currently have a situation where I want to have a function > > that accepts a parameter optionally. > > I would simply use a pointer

Re: dub / libs / rebuild not triggered

On Sunday, 1 April 2018 at 17:01:46 UTC, Robert M. Münch wrote: Hi, I have the following line in my dub.json file: "libs-windows-x86_64": ["user32", "kernel32", "gdi32", "b2d_playground"] b2d_playground is a C based .lib file. If this lib is updated and I run: dub build --arch=x86_64

Re: Optional parameters?

On Sunday, 1 April 2018 at 22:25:45 UTC, Jonathan M Davis wrote: How would a pointer help? Instead of doing foo(nullable(42)) he'd have to do foo(new int(42)) which is just one character shorter and ends up allocating on the heap, unlike with Nullable. - Jonathan M Davis foo();

So you want faster compilation with rdmd?

Have you ever wondered why `pragma(msg, "foo")` is appearing twice when compiling something with rdmd? Well, it's because rdmd is compiling the program twice and with evaluating all the Phobos template monstrosities this is easily ~30-40% of the entire build. There have been many attempts at

Re: Optional parameters?

On Sunday, 1 April 2018 at 22:44:45 UTC, Jonathan M Davis wrote: Which doesn't work in @safe code and doesn't work when you have an rvalue as you would when passing 42. Ultimately, using pointers ultimately either requires explicitly allocating stuff on the heap to be able to pass rvalues, or

Re: Deprecating this(this)

On Monday, April 02, 2018 00:25:52 Nicholas Wilson via Digitalmars-d wrote: > On Sunday, 1 April 2018 at 17:08:37 UTC, Andrei Alexandrescu > wrote: > > On 4/1/18 10:59 AM, Nicholas Wilson wrote: > > [...] > > int[] sneaky; > > struct A > > { > > > > private int[] innocent; > > this(this) >