Re: Taking arguments by value or by reference

On Saturday, 3 October 2020 at 23:00:46 UTC, Anonymouse wrote: I'm passing structs around (collections of strings) whose .sizeof returns 432. The readme for 2.094.0 includes the following: This release reworks the meaning of in to properly support all those use cases. in parameters will now b

Re: any chance to get it working on windows xp?

On Monday, 18 May 2020 at 05:36:01 UTC, Mike Parker wrote: [...] Unfortunately, the minimum Windows version "officially" supported is Windows 7: https://forum.dlang.org/post/ktfgps$2ghh$1...@digitalmars.com With no testing on XP, you are bound to run into difficulties trying to use the tools

Taking arguments by value or by reference

I'm passing structs around (collections of strings) whose .sizeof returns 432. The readme for 2.094.0 includes the following: This release reworks the meaning of in to properly support all those use cases. in parameters will now be passed by reference when optimal, [...] * Otherwise, if the

Re: Whats going on with this?

On Sat, Oct 3, 2020 at 11:30 PM Steven Schveighoffer via Digitalmars-d-learn wrote: > > > "StructMemberInitializers with the NonVoidInitializer syntax appear in > the lexical order of the fields in the StructDeclaration" seems to > suggest it will not call the constructor, but instead initialize

Re: Whats going on with this?

On 10/3/20 4:46 PM, Daniel Kozak wrote: On Sat, Oct 3, 2020 at 10:40 PM Daniel Kozak > wrote: I would say it is here you just need to read it carefully: https://dlang.org/spec/struct.html#static_struct_init For case specification is change I will paste it

Re: Whats going on with this?

On Sat, Oct 3, 2020 at 10:40 PM Daniel Kozak wrote: > I would say it is here you just need to read it carefully: > > https://dlang.org/spec/struct.html#static_struct_init > > For case specification is change I will paste it here: ''' If a StructInitializer is supplied, the fields are initialized

Re: Whats going on with this?

On Sat, Oct 3, 2020 at 4:45 PM Steven Schveighoffer via Digitalmars-d-learn wrote: > On 10/3/20 6:52 AM, claptrap wrote: > > On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer wrote: > >> On 10/2/20 7:28 PM, claptrap wrote: > >> > >>> Why would putting in the writeln cause it to fa

Re: How to hide a function return type in order to wrap several functions into an associated array?

On Sunday, 27 September 2020 at 20:03:21 UTC, Paul Backus wrote: On Sunday, 27 September 2020 at 18:54:11 UTC, tastyminerals wrote: [...] You can use an Algebraic [1] or SumType [2] for this: alias Feature = SumType!(ulong, double, bool); Feature numberOfPunctChars(string text) { // ...

Re: How to hide a function return type in order to wrap several functions into an associated array?

On Sunday, 27 September 2020 at 22:55:14 UTC, Ali Çehreli wrote: On 9/27/20 11:54 AM, tastyminerals wrote: > [...] input, a string. > [...] function does > [...] [...] Thank you. Quite an inspirational example with delegates.

Re: static foreach over constant range in @nogc block

On Saturday, 3 October 2020 at 14:19:27 UTC, Paul Backus wrote: On Saturday, 3 October 2020 at 14:17:45 UTC, tspike wrote: On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote: https://issues.dlang.org/show_bug.cgi?id=18439 Perfect! Thanks for getting back to me so quickly. FYI I

Re: Getting Field Names of a specific UDA in compile time.

On 10/3/20 10:16 AM, realhet wrote: I tried it to put into a function: auto getSymbolNamesByUDA(T, string uda)(){     string[] res;     static foreach(a; getSymbolsByUDA!(T, uda)) res ~= a.stringof;     return res; } D __traits give you strings, the std.traits thing is giving you symbols.

Re: Whats going on with this?

On 10/3/20 6:52 AM, claptrap wrote: On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer wrote: On 10/2/20 7:28 PM, claptrap wrote: Why would putting in the writeln cause it to fail? Is it maybe trying to create the foo at compile time? Yes, it is. Any static initialization of

Re: static foreach over constant range in @nogc block

On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote: https://issues.dlang.org/show_bug.cgi?id=18439 Perfect! Thanks for getting back to me so quickly.

Re: static foreach over constant range in @nogc block

On Saturday, 3 October 2020 at 14:17:45 UTC, tspike wrote: On Saturday, 3 October 2020 at 14:12:21 UTC, Paul Backus wrote: https://issues.dlang.org/show_bug.cgi?id=18439 Perfect! Thanks for getting back to me so quickly. FYI I am not Timon Gehr, the person who originally replied to you, but

Re: Getting Field Names of a specific UDA in compile time.

On Saturday, 3 October 2020 at 14:00:30 UTC, Adam D. Ruppe wrote: On Saturday, 3 October 2020 at 13:10:31 UTC, realhet wrote: I only managed to get the string[] by making a static foreach, but I don't know how to put that in an enum xxx = ...; statement. There's always other ways but general

Re: static foreach over constant range in @nogc block

On Saturday, 3 October 2020 at 14:02:08 UTC, tspike wrote: On Saturday, 3 October 2020 at 12:43:01 UTC, Timon Gehr wrote: It's a compiler bug, the same as this one: @nogc: void main(){ static immutable x = { int[] a; a~=1; return a; }(); } Ah, thank you for the quick reply! Do you know i

Re: Getting Field Names of a specific UDA in compile time.

On Saturday, 3 October 2020 at 13:10:31 UTC, realhet wrote: I only managed to get the string[] by making a static foreach, but I don't know how to put that in an enum xxx = ...; statement. There's always other ways but general rule: if you can get it one way, just wrap that up in a function a

Re: static foreach over constant range in @nogc block

On Saturday, 3 October 2020 at 12:43:01 UTC, Timon Gehr wrote: It's a compiler bug, the same as this one: @nogc: void main(){ static immutable x = { int[] a; a~=1; return a; }(); } Ah, thank you for the quick reply! Do you know if this bug has already been reported?

Getting Field Names of a specific UDA in compile time.

Hi, class Printer{ @("NODES") int gem1, gem2, gem3, gem4, gem5, head1, head2, head3, head4; import std.traits, std.meta; alias Nodes = getSymbolsByUDA!(typeof(this), "NODES"); enum NodeNames = ["gem1", "gem2", ]; } Is there a way to make an enum like the above with compile time p

Re: static foreach over constant range in @nogc block

On 03.10.20 13:18, tspike wrote: I came across an issue recently that I’m a little confused by. The following program fails to compile under LDC and DMD, though it compiles fine under GDC:     @nogc:     void main()     {     static foreach(i; 0 .. 4)     {     pragma(ms

Re: Whats going on with this?

On Friday, 2 October 2020 at 23:28:04 UTC, claptrap wrote: I cant see anything in the struct docs explaining why that array on the right hand side is automatically converted to a constructor call. I'm not sure exactly where it is in the docs but that's perfectly normal. Any declaration with

Re: vibe.d / experience / feedback

On 3 Oct 2020 at 13:14:57 CEST, "0xEAB" wrote: > On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote: >> On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin >> wrote: >>> Because standard implementation worse? >> >> What do you mean with "worse"? > > It's said to be pretty sl

static foreach over constant range in @nogc block

I came across an issue recently that I’m a little confused by. The following program fails to compile under LDC and DMD, though it compiles fine under GDC: @nogc: void main() { static foreach(i; 0 .. 4) { pragma(msg, i); } } Both DMD and LDC

Re: vibe.d / experience / feedback

On Saturday, 3 October 2020 at 07:54:58 UTC, Martin wrote: On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote: Because standard implementation worse? What do you mean with "worse"? It's said to be pretty slow…

Re: Whats going on with this?

On Saturday, 3 October 2020 at 00:15:02 UTC, Steven Schveighoffer wrote: On 10/2/20 7:28 PM, claptrap wrote: Why would putting in the writeln cause it to fail? Is it maybe trying to create the foo at compile time? Yes, it is. Any static initialization of static variables happens at compile

Re: vibe.d / experience / feedback

On Friday, 2 October 2020 at 09:46:09 UTC, Denis Feklushkin wrote: Because standard implementation worse? What do you mean with "worse"? In my experience std.json is a very thin implementation of the JSON spec - without/very low "magic". IMO this is what one wants in a std lib. Its a good sta