Re: How my little brother try D

Jesse Phillips wrote: > Oh this was the other thing I was looking for: > > http://stackoverflow.com/a/23231073/34435 > > C#'s move doesn't work across network. That's wrong AFAIK. Tobi

Re: So... let's document dmd

On Tuesday, 5 April 2016 at 13:47:55 UTC, Basile B. wrote: [...] by 4 or 5 softwares. Believe or not, in 2012 I've registered a company with the same error (.softwares). I don't know why...it hasnot been a commercial success.

Re: So... let's document dmd

On 4/5/2016 4:08 PM, Timon Gehr wrote: Some additional care will need to be taken, e.g. /+ or even simply /+ comment +/ that should not be a problem.

Re: So... let's document dmd

On 4/5/2016 7:59 PM, Basile B. wrote: Actually numbers is the only part of the D lexer where errors can be detected. There's no possible syntax errors otherwise. D's lexer.d detects many errors. Search lexer.d for "error".

[Issue 12100] __GENTYPE to generate ever different types

https://issues.dlang.org/show_bug.cgi?id=12100 Simen Kjaeraas changed: What|Removed |Added Keywords||pull

Re: So... let's document dmd

On Tuesday, 5 April 2016 at 21:37:09 UTC, Walter Bright wrote: On 4/5/2016 6:47 AM, Basile B. wrote: Also lexing number doesn't need to be as accurate as the front-end of the compiler (especially if the HL doesnt have a token type for the illegal "lexem". That is an interesting design

Re: non-utf8-decoding regex (for speed)?

On Tuesday, April 05, 2016 15:00:36 Timothee Cour via Digitalmars-d wrote: > Is there a way to avoid decoding (as utf8) when calling regex' apis? > or a plan to do so? > > use case: speed (no decoding) and avoiding throwing on invalid utf8 > sequences > > ideally this should allow: > > --- > auto

[Issue 15882] New: writeln on a bad dstring triggering assert(0) in std.utf.toUTF8

https://issues.dlang.org/show_bug.cgi?id=15882 Issue ID: 15882 Summary: writeln on a bad dstring triggering assert(0) in std.utf.toUTF8 Product: D Version: D2 Hardware: x86_64 OS: Windows Status:

[Issue 15692] Allow struct member initializer everywhere

https://issues.dlang.org/show_bug.cgi?id=15692 Alex Parrill changed: What|Removed |Added CC||initrd...@gmail.com ---

Re: Any usable SIMD implementation?

On 4/5/2016 4:17 AM, 9il wrote: What wrong for scientist to write `-mcpu=native`? Because it would affect all the code in the module and every template it imports, which is a problem if you are using 'static if' and want to compile different pieces with different settings.

Re: Release D 2.071.0

On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. Good work.

Re: Release D 2.071.0

On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module Bye bye 314, hope not to see ya soon.

Re: Decompressing bzip2

On 04/05/2016 03:33 PM, Mike Parker via Digitalmars-d-learn wrote: On Tuesday, 5 April 2016 at 19:27:20 UTC, Charles Hixson wrote: ... Are you asserting that scope is soon to be officially deprecated? I'm finding "shouldn't really be used at all anymore" a bit of a worrying statement, as I

Re: Release D 2.071.0

On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote: Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin

Re: So... let's document dmd

On 05.04.2016 10:46, Walter Bright wrote: On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no

[Issue 15877] [REG2.071beta] Some members are not visible by std.typecons.BlackHole

https://issues.dlang.org/show_bug.cgi?id=15877 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1

Release D 2.071.0

Glad to announce D 2.071.0. http://dlang.org/download.html This release fixes many long-standing issues with imports and the module system. See the changelog for more details. http://dlang.org/changelog/2.071.0.html -Martin

[Issue 15864] chmgen triggers exception in std.regex

https://issues.dlang.org/show_bug.cgi?id=15864 --- Comment #3 from Martin Nowak --- According to the stacktrace, it's triggered here. https://github.com/D-Programming-Language/dlang.org/blob/9d4ba62443d65a5c734b2162e355226919442b70/chmgen.d#L122 --

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On 05.04.2016 22:48, ZombineDev wrote: On Tuesday, 5 April 2016 at 20:13:59 UTC, Timon Gehr wrote: On 05.04.2016 17:29, ZombineDev wrote: On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote: {} for tuples hasn't worked out since it was deemed ambiguous with delegate syntax (was it

Re: Decompressing bzip2

On Tuesday, 5 April 2016 at 19:27:20 UTC, Charles Hixson wrote: ... Are you asserting that scope is soon to be officially deprecated? I'm finding "shouldn't really be used at all anymore" a bit of a worrying statement, as I much prefer the syntax used by scope. Why shouldn't it "be used at

Re: Convert wchar* to wstring?

On Tuesday, 5 April 2016 at 19:19:10 UTC, ag0aep6g wrote: On 05.04.2016 20:44, Thalamus wrote: [...] Aside: D has syntax for "// For wchar_t.": `import core.stdc.stddef: wchar_t;`. [...] wchar_t is not wchar. wstring is not (portably) compatible with a wchar_t array. If you actually

non-utf8-decoding regex (for speed)?

Is there a way to avoid decoding (as utf8) when calling regex' apis? or a plan to do so? use case: speed (no decoding) and avoiding throwing on invalid utf8 sequences ideally this should allow: --- auto s = cast(ubyte[]) "abcd"; //potentially not valid utf8 sequence auto r = cast(ubyte[])

Re: What's the rationale for considering "0x1.max" as invalid ?

On Tuesday, 5 April 2016 at 21:10:47 UTC, Basile B. wrote: On Tuesday, 5 April 2016 at 20:56:54 UTC, Alex Parrill wrote: On Tuesday, 5 April 2016 at 19:00:43 UTC, Basile B. wrote: 0x1.max // exponent expected in hex float 0x1 .max // OK 1.max // OK What's the ambiguity when it's an hex

Re: Any usable SIMD implementation?

On Tuesday, 5 April 2016 at 21:29:41 UTC, Walter Bright wrote: I want to make it clear that dmd does not generate AFX specific code, has no switch to enable AFX code generation and has no basis for setting predefined version identifiers for it. How about adding a "__target(...)"

Re: So... let's document dmd

On 4/5/2016 4:34 AM, Jacob Carlborg wrote: I agree very much with this. Unfortunately many (most?) editors use their own weird syntax to describe grammars for syntax highlighting and cannot use a proper lexer/parser. Haha, MicroEmacs is written in D, so just use D code :-) I don't really

Re: So... let's document dmd

On 4/5/2016 6:47 AM, Basile B. wrote: Also lexing number doesn't need to be as accurate as the front-end of the compiler (especially if the HL doesnt have a token type for the illegal "lexem". That is an interesting design point. If I was doing a highlighter, I'd highlight in red tokens that

Re: Any usable SIMD implementation?

On 4/5/2016 4:07 AM, 9il wrote: On Tuesday, 5 April 2016 at 10:30:19 UTC, Walter Bright wrote: On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified

[Issue 15881] New: approxEqual Ignores maxAbsDiff

https://issues.dlang.org/show_bug.cgi?id=15881 Issue ID: 15881 Summary: approxEqual Ignores maxAbsDiff Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1

Re: What's the rationale for considering "0x1.max" as invalid ?

On Tuesday, 5 April 2016 at 20:56:54 UTC, Alex Parrill wrote: On Tuesday, 5 April 2016 at 19:00:43 UTC, Basile B. wrote: 0x1.max // exponent expected in hex float 0x1 .max // OK 1.max // OK What's the ambiguity when it's an hex literal ? It's potentially ambiguous with hexadecimal floating

[Issue 15869] RVO can overwrite argument

https://issues.dlang.org/show_bug.cgi?id=15869 --- Comment #5 from ag0ae...@gmail.com --- (In reply to Yuxuan Shui from comment #4) > Looks like if clobber is not called in constructor, the return value is > stored into a temporary variable and then copied into xx using Set.opAssign. > > I'm not

[Issue 15869] RVO can overwrite argument

https://issues.dlang.org/show_bug.cgi?id=15869 --- Comment #4 from Yuxuan Shui --- Looks like if clobber is not called in constructor, the return value is stored into a temporary variable and then copied into xx using Set.opAssign. I'm not sure if this is correct since Set

Re: What's the rationale for considering "0x1.max" as invalid ?

On Tuesday, 5 April 2016 at 19:00:43 UTC, Basile B. wrote: 0x1.max // exponent expected in hex float 0x1 .max // OK 1.max // OK What's the ambiguity when it's an hex literal ? It's potentially ambiguous with hexadecimal floating point numbers 0xdeadbeef.p5 // hex float or hex int + method?

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 20:13:59 UTC, Timon Gehr wrote: On 05.04.2016 17:29, ZombineDev wrote: On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote: {} for tuples hasn't worked out since it was deemed ambiguous with delegate syntax (was it for the case of empty

[Issue 15625] Internal error: backend/elfobj.c 1014

https://issues.dlang.org/show_bug.cgi?id=15625 --- Comment #3 from Mark Isaacson --- Super excited that you know what you're doing/how to root cause this. I had/have no idea how to proceed with fixing this. --

[Issue 15869] RVO can overwrite argument

https://issues.dlang.org/show_bug.cgi?id=15869 --- Comment #3 from ag0ae...@gmail.com --- (In reply to Yuxuan Shui from comment #2) > I think the expected behavior here is a compile error. I think it should compile and set xx.a.value to 1. The compiler manages to do that when `a = clobber();` is

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On 05.04.2016 17:29, ZombineDev wrote: On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote: {} for tuples hasn't worked out since it was deemed ambiguous with delegate syntax (was it for the case of empty statements/tuple?). How about the following syntax instead: {} //

[Issue 15788] [REG2.069] ICE assert triggered on overloaded function

https://issues.dlang.org/show_bug.cgi?id=15788 ag0ae...@gmail.com changed: What|Removed |Added CC||andy.pj.han...@gmail.com --- Comment #4

[Issue 15879] Compiler crashes when two template structs have the same name

https://issues.dlang.org/show_bug.cgi?id=15879 ag0ae...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC|

Re: gchunt v0.2.0

On Tuesday, 5 April 2016 at 19:15:04 UTC, Pradeep Gowda wrote: This is somewhat tangentially related to the announcement.. but how does one run "-vgc" switch with "dub"? Running dmd -vgc with a project with dependencies (eg: docopt) failed because dmd could not find the dependencies.

Re: What's the rationale for considering "0x1.max" as invalid ?

On Tuesday, 5 April 2016 at 19:00:43 UTC, Basile B. wrote: 0x1.max // exponent expected in hex float 0x1 .max // OK 1.max // OK What's the ambiguity when it's an hex literal ? https://issues.dlang.org/show_bug.cgi?id=15880

[Issue 15880] New: int hex literals properties are rejected

https://issues.dlang.org/show_bug.cgi?id=15880 Issue ID: 15880 Summary: int hex literals properties are rejected Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority:

Re: Decompressing bzip2

On 04/04/2016 04:38 PM, Mike Parker via Digitalmars-d-learn wrote: On Monday, 4 April 2016 at 21:32:10 UTC, stunaep wrote: Can you please explain what the scope keyword does and if there scope was originally intended to be used primarily with classes in order to get deterministic

Re: uniform initialization in D (as in C++11): i{...}

On 05.04.2016 21:24, Timon Gehr wrote: On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote: what's D's answer for C++11's uniform initialization [1] which allows DRY code? If it's just about DRY... NVM, I see those points have been brought up already (the thread was split into

Re: overriding methods

On Tuesday, 5 April 2016 at 18:54:39 UTC, stunaep wrote: I had no error on the examples I posted, only when using @Override previously. It just says to use override attribute instead of @Override Unlike in Java, D's override indicator doesn't look like an annotation, it's just a keyword

Re: uniform initialization in D (as in C++11): i{...}

On 05.04.2016 07:39, Timothee Cour via Digitalmars-d wrote: what's D's answer for C++11's uniform initialization [1] which allows DRY code? If it's just about DRY, D is in quite good shape. A fun(A a, int b) { alias i=typeof(return); if(b==1) return i(0,1); else if(b==2) return

Re: Convert wchar* to wstring?

On 05.04.2016 20:44, Thalamus wrote: import core.stdc.stddef; // For wchar_t. This is defined differently for Windows vs POSIX. import core.stdc.wchar_; // For wcslen. Aside: D has syntax for "// For wchar_t.": `import core.stdc.stddef: wchar_t;`. wstring toWstring(wchar_t* value) {

Re: gchunt v0.2.0

On Tuesday, 5 April 2016 at 18:47:38 UTC, Dmitry Olshansky wrote: New release of a tool that generates nice summary reports for static analysis of GC usage. It's a simple postprocessor for the compiler's -vgc output. https://github.com/DmitryOlshansky/gchunt/releases Updated to the latest

What's the rationale for considering "0x1.max" as invalid ?

0x1.max // exponent expected in hex float 0x1 .max // OK 1.max // OK What's the ambiguity when it's an hex literal ?

[Issue 15879] New: Compiler crashes when two template structs have the same name

https://issues.dlang.org/show_bug.cgi?id=15879 Issue ID: 15879 Summary: Compiler crashes when two template structs have the same name Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: overriding methods

On 04/05/2016 11:54 AM, stunaep wrote: > when using @Override previously. It just says to use override > attribute instead of @Override > source\game\client.d(7,3): Error: undefined identifier 'Override' Note that it doesn't say _instead of Override_. Override is an undefined symbol in your

Re: overriding methods

On Tuesday, 5 April 2016 at 18:54:39 UTC, stunaep wrote: I had no error on the examples I posted, only when using @Override previously. It just says to use override attribute instead of @Override source\game\client.d(8,20): Deprecation: implicitly overriding base class method

Re: overriding methods

On Tuesday, 5 April 2016 at 18:42:33 UTC, Adam D. Ruppe wrote: On Tuesday, 5 April 2016 at 18:38:43 UTC, stunaep wrote: I get a deprecation warning with @Override, but I was unable to find the proper way to do it. What error message exactly are you getting and on what code? Both styles you

gchunt v0.2.0

New release of a tool that generates nice summary reports for static analysis of GC usage. It's a simple postprocessor for the compiler's -vgc output. https://github.com/DmitryOlshansky/gchunt/releases Updated to the latest compiler/libarires and also detects dup/idup unreported by -vgc

Re: Convert wchar* to wstring?

On Tuesday, 5 April 2016 at 11:26:44 UTC, Thalamus wrote: Thanks everyone! You've all been very helpful. For anyone who has the same question and happens on this thread, I wanted to post what I finally came up with. I combined the information everyone in this thread gave me with what I saw

Re: overriding methods

On Tuesday, 5 April 2016 at 18:38:43 UTC, stunaep wrote: I get a deprecation warning with @Override, but I was unable to find the proper way to do it. What error message exactly are you getting and on what code? Both styles you put there should work equally well.

overriding methods

I get a deprecation warning with @Override, but I was unable to find the proper way to do it. Am I meant to add override before the method like this? override public void startThread(Thread t, int pri) { ... } Am I meant to wrap the entire method in override { } like this? override {

Re: Get third part of front-end version number

On Tuesday, 5 April 2016 at 18:01:05 UTC, Nick Sabalausky wrote: These days, DMD/DMDFE version numbers are three parts, ex: 2.070.1. I can get the first two via std.compiler.version_major and std.compiler.version_minor. Is there a way to get the third part? I know I can "dmd --help | grep

[Issue 13017] opEquals for null std.typecons.Nullable

https://issues.dlang.org/show_bug.cgi?id=13017 Luís Marques changed: What|Removed |Added CC||l...@luismarques.eu ---

Get third part of front-end version number

These days, DMD/DMDFE version numbers are three parts, ex: 2.070.1. I can get the first two via std.compiler.version_major and std.compiler.version_minor. Is there a way to get the third part? I know I can "dmd --help | grep DMD", but that only works for DMD. GDC's "gdc --version" doesn't

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 16:34:49 UTC, jmh530 wrote: On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote: Action action = {}; // error: `{}` is an empty tuple, can't be assigned to delegates auto t = {}; // deduced as an empty tuple. Also, the non-empty {} syntax can't be mistaken

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 16:56:15 UTC, Jack Stouffer wrote: Tuple and AliasSeq are library types, so the chance that they will be added into the language is slim to none. Yes on Tuple, but AliasSeq actually is in the language (just unnamed there, it is what you get with T... in a template

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote: {} for tuples hasn't worked out since it was deemed ambiguous with delegate syntax (was it for the case of empty statements/tuple?). How about the following syntax instead: {} // delegate (existing syntax) q{...} // string

[Issue 10823] Aligned malloc functions for C heap

https://issues.dlang.org/show_bug.cgi?id=10823 Jack Stouffer changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 14053] "Hello world" generates bloat in the object file

https://issues.dlang.org/show_bug.cgi?id=14053 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com

[Issue 13240] semantic3 for FormatSpec!char is extremely slow (takes ~40ms)

https://issues.dlang.org/show_bug.cgi?id=13240 Jack Stouffer changed: What|Removed |Added Keywords||performance

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 15:29:06 UTC, ZombineDev wrote: Action action = {}; // error: `{}` is an empty tuple, can't be assigned to delegates auto t = {}; // deduced as an empty tuple. Also, the non-empty {} syntax can't be mistaken for a function literal because non-empty function literals

Re: uniform initialization in D (as in C++11): i{...}

On Monday, April 04, 2016 22:39:25 Timothee Cour via Digitalmars-d wrote: > what's D's answer for C++11's uniform initialization [1] which allows DRY > code? > > Could we have this: > > struct A{ > int a; > int b; > } > > A fun(A a, int b) { > if(b==1) return i{0,1}; > else if(b==2)

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 14:57:14 UTC, Adam D. Ruppe wrote: On Tuesday, 5 April 2016 at 14:45:33 UTC, ZombineDev wrote: Yeah, that's what I had in mind. new Object{}, int(3) -> int{3}, T() -> T{} (in generic code), and {42, "tuple"} where the type can be deduced. Unfortunately the (1, 2,

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 05:45:08 UTC, Timothee Cour wrote: {} for tuples hasn't worked out since it was deemed ambiguous with delegate syntax (was it for the case of empty statements/tuple?). How about the following syntax instead: {} // delegate (existing syntax) q{...} // string

[Issue 13724] std.datetime.timeIt

https://issues.dlang.org/show_bug.cgi?id=13724 --- Comment #8 from Steven Schveighoffer --- (In reply to Jack Stouffer from comment #7) > Doesn't std.datetime.benchmark handle this? See above discussion :) --

[Issue 13422] std.ascii has isAlphaNum but std.uni doesn't

https://issues.dlang.org/show_bug.cgi?id=13422 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/0c642797cd79bd4857afaac893ec443907218205 Fix Issue 13422:

[Issue 13422] std.ascii has isAlphaNum but std.uni doesn't

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

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 14:45:33 UTC, ZombineDev wrote: Yeah, that's what I had in mind. new Object{}, int(3) -> int{3}, T() -> T{} (in generic code), and {42, "tuple"} where the type can be deduced. Unfortunately the (1, 2, 3) syntax is can't be used for tuples because it is

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 11:35:35 UTC, Jacob Carlborg wrote: On 2016-04-05 09:47, ZombineDev wrote: D currently supports Point3 p = { x:1, y:2, z:3 }; It just needs to be extended to work in more places. https://issues.dlang.org/show_bug.cgi?id=15692 That's only for structs. A uniform

[Issue 14966] Comparing two std.xml.Document result in infinite recursion

https://issues.dlang.org/show_bug.cgi?id=14966 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/7cdd7098be255ec051831f9b56741701c6a1a57e fix issue 14966:

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On 05.04.2016 07:45, Timothee Cour via Digitalmars-d wrote: How about the following syntax instead: {} // delegate (existing syntax) q{...} // string literal (existing syntax) t{...} // tuple(a,b) (proposed syntax) T{...} // TypeTuple!(a,b) (proposed syntax) In existing syntax, most

[Issue 14966] Comparing two std.xml.Document result in infinite recursion

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

Re: So... let's document dmd

On Tuesday, 5 April 2016 at 08:46:30 UTC, Walter Bright wrote: On 1/16/2016 7:13 AM, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one

Re: Using a macro for a function signature

On Tuesday, 5 April 2016 at 13:17:38 UTC, Anonymouse wrote: You can't get rid of the signature completely as the functions still need a parameter list with x declared. You will get "Error: undefined identifier 'x'" otherwise. You can largely omit the *type* of x if it can be inferred from the

Re: Using a macro for a function signature

On 05.04.2016 13:35, pineapple wrote: alias somelongsignature = int(in int x); alias somelongsignature = int function(in int); Or if you want to accept methods and such: alias somelongsignature = int delegate(in int); You can name the parameter, but it won't be part of the type. int

Re: Using a macro for a function signature

On Tuesday, 5 April 2016 at 11:35:24 UTC, pineapple wrote: If I have a common function signature I'm using throughout my code, and I feel like there should be a way to condense it using a macro. The intuitive method isn't working, but this seems like something D would be able to do. What've I

[Issue 15878] Discarding return value prevents inlining

https://issues.dlang.org/show_bug.cgi?id=15878 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from

[Issue 15483] static if prevents inlining

https://issues.dlang.org/show_bug.cgi?id=15483 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 7625] inlining only works with explicit else branch

https://issues.dlang.org/show_bug.cgi?id=7625 --- Comment #9 from Kenji Hara --- *** Issue 15483 has been marked as a duplicate of this issue. *** --

[Issue 15878] New: Discarding return value prevents inlining

https://issues.dlang.org/show_bug.cgi?id=15878 Issue ID: 15878 Summary: Discarding return value prevents inlining Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: rejects-valid

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 11:35:35 UTC, Jacob Carlborg wrote: On 2016-04-05 09:47, ZombineDev wrote: D currently supports Point3 p = { x:1, y:2, z:3 }; It just needs to be extended to work in more places. https://issues.dlang.org/show_bug.cgi?id=15692 That's only for structs. A uniform

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote: q{...} // comment (existing syntax) That is syntax for a string literal, not a comment (though unlike other string literals, the contents must be valid D tokens and editors usually do not highlight them as strings).

Re: uniform initialization in D (as in C++11): i{...}

On Tuesday, 5 April 2016 at 05:39:25 UTC, Timothee Cour wrote: As for which syntax to use, that's an orthogonal question, but here I used i{} since {} (from C++11) is already used by delegates (with tuples also being discussed at some point, which didn't pan out bc someone mentioned it was

[Issue 15829] hasElaborateDestructor doesn't work for classes

https://issues.dlang.org/show_bug.cgi?id=15829 --- Comment #3 from ZombineDev --- But what about generic code that already (wrongly) relies on hasElaborateDestructor (such as std.experimental.allocator)? Should we add hasElaborateDestructor2 that handles both classes and

Re: Using a macro for a function signature

Ah, aside from the mismatched "examplefunc" numbers - please disregard Can't post example code without stupid typos for the life of me

Using a macro for a function signature

If I have a common function signature I'm using throughout my code, and I feel like there should be a way to condense it using a macro. The intuitive method isn't working, but this seems like something D would be able to do. What've I got wrong in this example? alias somelongsignature =

Re: uniform initialization in D (as in C++11): i{...}

On 2016-04-05 09:47, ZombineDev wrote: D currently supports Point3 p = { x:1, y:2, z:3 }; It just needs to be extended to work in more places. https://issues.dlang.org/show_bug.cgi?id=15692 That's only for structs. A uniform initialization syntax needs to be ... uniform. It has to work for

[Issue 15829] hasElaborateDestructor doesn't work for classes

https://issues.dlang.org/show_bug.cgi?id=15829 Nick Treleaven changed: What|Removed |Added CC|

Re: So... let's document dmd

On 2016-01-16 16:13, H. S. Teoh via Digitalmars-d wrote: I disagree. I think having the dmd itself (lexer, parser, etc.) as a library (with the dmd executable merely being the default frontend) will do D a lot of good. For one thing, IDE's will no longer need to reinvent a D parser for the

Re: Segmentation Fault on rt.tlsgc.init

On 2016-04-05 11:46, tcak wrote: If I create many threads (starts, does a short work, and ends) repeatedly (>10,000), at some point rt.tlsgc.init() gives SEGMENTATION_FAULT. It doesn't check whether malloc fails to allocate any memory, and I cannot find the source code of

Re: Convert wchar* to wstring?

Thanks everyone! You've all been very helpful.

Re: Any usable SIMD implementation?

On Tuesday, 5 April 2016 at 10:27:46 UTC, Walter Bright wrote: On 4/5/2016 2:03 AM, John Colvin wrote: There's a line between trying to standardize everything and letting add-on libraries be free to innovate. Besides, I think it's a poor design to customize the app for only one SIMD type. A

Re: Any usable SIMD implementation?

On Tuesday, 5 April 2016 at 10:30:19 UTC, Walter Bright wrote: On 4/5/2016 2:39 AM, 9il wrote: On Tuesday, 5 April 2016 at 08:34:32 UTC, Walter Bright wrote: 1. This would help to eliminate configuration bugs. 2. This would reduce work for users and simplified user experience. 3. This is

Re: PostgreSQL. Unknown parameter of configuration : "autocommit"

On Tuesday, 5 April 2016 at 10:30:58 UTC, Suliman wrote: http://www.symmetricds.org/issues/view.php?id=2439 http://www.postgresql.org/docs/9.5/static/ecpg-sql-set-autocommit.html - doesn't look deprecated or anything.

Re: Any usable SIMD implementation?

On Tuesday, 5 April 2016 at 09:39:21 UTC, 9il wrote: 3. This is possible and not very hard to implement if I am not wrong. Last time I looked into this (related to implementing @target, see [1]), I only found some Clang code dealing with this, but now I found LLVM functions about

  1   2   >