Re: D future ...

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: I split this from the "Re: A betterC modular standard library?" topic because my response is will be too much off-topic but the whole thread is irking me the wrong way. I see some of the same argument coming up all the time, with a

Re: Red Hat's issues in considering the D language

On 2016-12-21 00:08, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well.

Re: CTFE Status

On Tuesday, 20 December 2016 at 20:30:43 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: I hope that my reports give a little insight into what issues I am facing, and why it is taking so long. There's a left parenthesis too much on line 3320 in ctfe_bc.d

D3D12 memory issues

Hello guys, I have DirectX 12 code that doesn't work in D (it works in C++), as the subject says this can be related to D heap and/or thread local storage. code can be found here (build with dmd -m32mscoff)

[Issue 16997] Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 --- Comment #4 from Ketmar Dark --- p.s.: i'm not that smart, tbh, i understood the rationale behind the design after alot of hard thinking. --

[Issue 16997] Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 --- Comment #3 from Ketmar Dark --- as for the question: promotion rules are what they are currently to allow this: byte n; n = -n; if unary minus will promote `n`, you will need to add `cast` there. and negate never ever

[Issue 16997] Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 Ketmar Dark changed: What|Removed |Added Attachment #1626|0 |1 is

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 02:27:02 UTC, Andrei Alexandrescu wrote: If it's elidable, it's as good as a bug in the program. Must be either a compile-time error or a special case. -- Andrei I can't see it ending well to make it this kind of special case. For example, one day someone

Re: Improvement in pure functions specification

On 12/20/16 8:54 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: Isn't that impure by definition?! How can tracing execution even be remotely considered

Re: Improvement in pure functions specification

On Tue, Dec 20, 2016 at 08:16:36PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: > > Isn't that impure by definition?! How can tracing execution even be > > remotely considered pure? > > That's why the compiler is required

[Issue 16996] std.algorithm.remove with SwapStrategy.unstable removes more entries

https://issues.dlang.org/show_bug.cgi?id=16996 safety0ff.bugz changed: What|Removed |Added Keywords||pull --- Comment

Re: Improvement in pure functions specification

On 12/20/16 8:02 PM, H. S. Teoh via Digitalmars-d wrote: Isn't that impure by definition?! How can tracing execution even be remotely considered pure? That's why the compiler is required compulsively to call it. -- Andrei

Re: Improvement in pure functions specification

On 12/20/16 8:10 PM, Meta wrote: The compiler will have to be changed for this part. Currently it's a warning (or maybe it was an error, can't remember) to call a strongly pure function returning void without doing `cast(void)fun()`. Interesting. As soon as the spec change is merged, we get to

Re: Improvement in pure functions specification

On Wednesday, 21 December 2016 at 00:58:38 UTC, Andrei Alexandrescu wrote: On 12/20/16 7:40 PM, Timon Gehr wrote: On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called

Re: Improvement in pure functions specification

On Tue, Dec 20, 2016 at 07:58:38PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 7:40 PM, Timon Gehr wrote: > > On 20.12.2016 23:49, Andrei Alexandrescu wrote: > > > https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Good, except: > > > > "$(P `pure` functions

Re: Improvement in pure functions specification

On Tuesday, December 20, 2016 19:58:38 Andrei Alexandrescu via Digitalmars-d wrote: > On 12/20/16 7:40 PM, Timon Gehr wrote: > > On 20.12.2016 23:49, Andrei Alexandrescu wrote: > >> https://github.com/dlang/dlang.org/pull/1528 -- Andrei > > > > Good, except: > > > > "$(P `pure` functions

Re: Improvement in pure functions specification

On 12/20/16 7:40 PM, Timon Gehr wrote: On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function

[Issue 16146] postblit is not called on struct creation with "{field:value}" syntax

https://issues.dlang.org/show_bug.cgi?id=16146 --- Comment #2 from Ketmar Dark --- yeah, seems to be fixed. tnx! --

Re: Improvement in pure functions specification

On 20.12.2016 23:49, Andrei Alexandrescu wrote: https://github.com/dlang/dlang.org/pull/1528 -- Andrei Good, except: "$(P `pure` functions returning `void` will be always called even if it is strongly `pure`. The implementation must assume the function does something outside the confines of

[Issue 16997] Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 --- Comment #1 from ponce --- Created attachment 1626 --> https://issues.dlang.org/attachment.cgi?id=1626=edit Patch in ketmar DMD fork ("aliced") to make unary +/- on small integers a warning --

[Issue 16997] Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 Ketmar Dark changed: What|Removed |Added CC|

[Issue 16997] New: Real-life evidence for integer promotion of unary minus creating bugs when porting C code

https://issues.dlang.org/show_bug.cgi?id=16997 Issue ID: 16997 Summary: Real-life evidence for integer promotion of unary minus creating bugs when porting C code Product: D Version: D2 Hardware: All OS: All

Re: Red Hat's issues in considering the D language

On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any

Re: Red Hat's issues in considering the D language

On Tuesday, 20 December 2016 at 23:08:28 UTC, Andrei Alexandrescu wrote: https://gist.github.com/ximion/77dda83a9926f892c9a4fa0074d6bf2b Pretty cool. One of the DUB issues is: There is no default "release-build-with-debug-symbols" target. Seems like a documentation bug, because: dub

Red Hat's issues in considering the D language

Hello, a few engineers at Red Hat are taking a look at using the D language on the desktop and have reached out to us. They have created a list of issues. We are on the top-level ones, and of course would appreciate any community help as well.

Improvement in pure functions specification

https://github.com/dlang/dlang.org/pull/1528 -- Andrei

[Issue 16996] std.algorithm.remove with SwapStrategy.unstable removes more entries

https://issues.dlang.org/show_bug.cgi?id=16996 safety0ff.bugz changed: What|Removed |Added Severity|enhancement |normal ---

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a

[Issue 16996] std.algorithm.remove with SwapStrategy.unstable removes more entries

https://issues.dlang.org/show_bug.cgi?id=16996 safety0ff.bugz changed: What|Removed |Added Status|RESOLVED|REOPENED

[Issue 16996] std.algorithm.remove with SwapStrategy.unstable removes more entries

https://issues.dlang.org/show_bug.cgi?id=16996 safety0ff.bugz changed: What|Removed |Added Status|NEW |RESOLVED

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/20/2016 05:08 PM, Andrei Alexandrescu wrote: On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/20/2016 03:46 AM, Joakim wrote: I didn't just say "eh:" I gave evidence for why I think the problem is minimal and asked why it's so important to scope those last 3-4 imported modules too, which you didn't answer. You have asked for a smoking gun, and one has been found. I have just

Re: meaning of "auto ref const"?

On Tuesday, 20 December 2016 at 20:08:32 UTC, Ali Çehreli wrote: If the purpose is optimization, the good news are Yes it is :) * Classes are already reference types so there is no lvalue or rvalue reference distinction there Ok, this one is quite intuitive. import std.stdio; ...

[Issue 16996] New: std.algorithm.remove with SwapStrategy.unstable removes more entries

https://issues.dlang.org/show_bug.cgi?id=16996 Issue ID: 16996 Summary: std.algorithm.remove with SwapStrategy.unstable removes more entries Product: D Version: D2 Hardware: x86_64 OS: Linux

Re: meaning of "auto ref const"?

On Tuesday, 20 December 2016 at 19:24:32 UTC, Ali Çehreli wrote: As a general rule, 'auto ref' should probably be const. If the purpose of 'ref' is so that the argument would be mutated, then allowing a copy of an rvalue to this function could very well be a bug: struct S { int i; }

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 19.12.2016 06:31, deadalnix wrote: On Sunday, 18 December 2016 at 23:18:27 UTC, Andrei Alexandrescu wrote: Great, thanks. Please take a look at the accuracy of the discussion. I expanded the "Workaround" section and moved it near the top. https://github.com/dlang/DIPs/pull/51

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 20 December 2016 at 20:51:54 UTC, Andrei Alexandrescu wrote: I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

I've asked Joakim about this via email just now, likely other folks also know the answer: 1. I found these PRs related to local imports: https://github.com/dlang/phobos/pull/4361 https://github.com/dlang/phobos/pull/4365 https://github.com/dlang/phobos/pull/4370

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On 12/20/2016 09:31 AM, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g. renaming a module cascades

Re: ModuleInfo, factories, and unittesting

On 12/20/2016 11:05 AM, Dicebot wrote: Yes, pretty much. What ways do you have in mind? I am only aware of two: 1) ModuleInfo 2) https://dlang.org/spec/traits.html#getUnitTests Put pointers to them in a special segment.

Re: CTFE Status

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: I hope that my reports give a little insight into what issues I am facing, and why it is taking so long. There's a left parenthesis too much on line 3320 in ctfe_bc.d ;)

Re: Vibe.d form file attributes

On Tuesday, 20 December 2016 at 18:42:11 UTC, WebFreak001 wrote: On Tuesday, 20 December 2016 at 18:22:51 UTC, aberba wrote: [...] iterate over req.files like this instead: foreach (name, picture; req.files) // name is "picture[]" now { ... } Nice. [...] pragma(msg,

Re: D future ...

On Tuesday, 20 December 2016 at 08:20:32 UTC, LiNbO3 wrote: On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote: On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote: On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote: On 12/19/2016 11:12 PM, Andrei Alexandrescu

Re: D books for $5

On Friday, 16 December 2016 at 05:43:02 UTC, Kai Nacke wrote: Hi all, Packt Publishing offers eBooks for $5 for a limited time. If your collection of D eBooks is still incomplete then this is a great chance for you. :-) D Cookbook by Adam D. Ruppe

Re: CTFE Status

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: On a different note. Thanks for your continued moral support. It is nice to know that my work is eagerly awaited by people. As always I am sorry for the long time it takes. I hope that my reports give a little insight into what

Re: Multidimensional array access

Thanks for the explanation

Re: [your donation here]

Note that the donations are made in USD, which isn't surprising but if you don't live in the US you could end up donating more than you intended to with the difference in currencies.

Re: D future ...

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote: I split this from the "Re: A betterC modular standard library?" topic because my response is will be too much off-topic but the whole thread is irking me the wrong way. I see some of the same argument coming up all the time, with a

Re: Multidimensional array access

On 12/20/2016 11:59 AM, somebody wrote: I though D should have syntax similarities with C, but recently I've found that array indexing in D is different. Suppose we have a code: import std.stdio; void main () { wstring[6][2] strings; strings[2][0] = "test"; } It fails to compile

Re: CTFE Status

On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote: At this point it might take another month until function calls are working. I admire your endurance.

Re: Multidimensional array access

On Tuesday, 20 December 2016 at 19:59:41 UTC, somebody wrote: I though D should have syntax similarities with C, but recently I've found that array indexing in D is different. Suppose we have a code: import std.stdio; void main () { wstring[6][2] strings; strings[2][0] = "test"; }

Re: D future ...

On Tuesday, 20 December 2016 at 19:15:37 UTC, Chris M. wrote: On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote: Seb just made a giant post listing all the things that could be done to help improve D, that could to be pinned somewhere so that everyone can see it. Maybe something

Re: meaning of "auto ref const"?

On 12/18/2016 05:14 AM, Picaud Vincent wrote: > Another interrogation for me, who come from C++, is how to translate > into D: > > template void foo(T&& t); If it means "rvalue reference"[1], then there is no equivalent is D because D does not allow references to rvalues, even if const. If

Re: Multiple return value as requirements for safety and performance

On 20.12.2016 14:47, Ilya Yaroshenko wrote: One good thing for safety and CTFE is allow multiple return value. In combination with `auto ref` it is _very_ powerful: auto ref front() { // Returns 2 values, each value is returned by reference if possible return (a.front, b.front); }

Multidimensional array access

I though D should have syntax similarities with C, but recently I've found that array indexing in D is different. Suppose we have a code: import std.stdio; void main () { wstring[6][2] strings; strings[2][0] = "test"; } It fails to compile because of error: "./main.d(6): Error:

[Issue 16967] No switch case fallthrough warnings in in/out contracts

https://issues.dlang.org/show_bug.cgi?id=16967 bitter.ta...@gmx.com changed: What|Removed |Added CC||bitter.ta...@gmx.com --- Comment #1

[Issue 16146] postblit is not called on struct creation with "{field:value}" syntax

https://issues.dlang.org/show_bug.cgi?id=16146 bitter.ta...@gmx.com changed: What|Removed |Added CC||bitter.ta...@gmx.com --- Comment #1

Re: meaning of "auto ref const"?

As a general rule, 'auto ref' should probably be const. If the purpose of 'ref' is so that the argument would be mutated, then allowing a copy of an rvalue to this function could very well be a bug: struct S { int i; } void foo()(auto ref S s) { s.i = 42; // <-- Cannot be observed if

Re: D future ...

On Tuesday, 20 December 2016 at 19:11:11 UTC, Chris M. wrote: Seb just made a giant post listing all the things that could be done to help improve D, that could to be pinned somewhere so that everyone can see it. Maybe something like that should be made every time a new high-level vision is

[Issue 16480] Local selective imports hide member functions

https://issues.dlang.org/show_bug.cgi?id=16480 bitter.ta...@gmx.com changed: What|Removed |Added CC||bitter.ta...@gmx.com --- Comment #1

Re: D future ...

On Tuesday, 20 December 2016 at 18:01:23 UTC, jmh530 wrote: It's a fair point, but people only know that all these rants have come up a million times if they've been following the newsgroup for a while. It's the kind of thing where most forums have a read me that says something like, yes we

[Issue 8656] Different naming of member base/next in TypeInfo_Const in object_.d and object.di

https://issues.dlang.org/show_bug.cgi?id=8656 Rainer Schuetze changed: What|Removed |Added Status|NEW |RESOLVED

Re: ModuleInfo, factories, and unittesting

On 12/20/2016 08:33 PM, Walter Bright wrote: > On 12/20/2016 12:01 AM, Dicebot wrote: >> We rely on ModuleInfo for custom test runner in ocean >> (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d). >> >> Static introspection can't provide same functionality

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:47:38 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote: DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D. I wonder if it might be possible to add the tuple syntax

Re: Vibe.d form file attributes

On Tuesday, 20 December 2016 at 18:22:51 UTC, aberba wrote: [...] Now I wanted to implement this in D (vibe.d) and here is what I did in the file upload handler. void upload(HTTPServerRequest req, HTTPServerResponse res) { import std.stdio; foreach(picture; req.files) // req.files

Re: ModuleInfo, factories, and unittesting

On 12/20/2016 01:15 PM, Atila Neves wrote: On Monday, 19 December 2016 at 18:29:13 UTC, Andrei Alexandrescu wrote: On 12/19/16 12:25 PM, Atila Neves wrote: On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote: [...] I'd forgotten about separate compilation. The issue there is

Re: ModuleInfo, factories, and unittesting

On 12/20/2016 12:01 AM, Dicebot wrote: We rely on ModuleInfo for custom test runner in ocean (https://github.com/sociomantic-tsunami/ocean/blob/v2.x.x/src/ocean/core/UnitTestRunner.d). Static introspection can't provide same functionality in general case (even if all bugs will be fixed) because

Vibe.d form file attributes

In PHP, I am able to access the name attribute of multiple files submitted through forms at the server side in $_FILES global. For example, a file input with name="picture[]" will allow me to upload multiples files with the same attribute name. This can be access in PHP as; $files =

Re: ModuleInfo, factories, and unittesting

On Monday, 19 December 2016 at 18:29:13 UTC, Andrei Alexandrescu wrote: On 12/19/16 12:25 PM, Atila Neves wrote: On Monday, 19 December 2016 at 17:11:38 UTC, Adam D. Ruppe wrote: [...] I'd forgotten about separate compilation. The issue there is the algorithm for naming unittest blocks

Re: D future ...

On Tuesday, 20 December 2016 at 15:44:03 UTC, Dicebot wrote: I am really tired of this recurring bullshit of random guys coming up and acting as if they have any right to demand anything. You distract those few that are willing to do the work from focusing on it, you are not capable of

[Issue 16995] New: __traits(getUnittests) doesn't work with separate compilation

https://issues.dlang.org/show_bug.cgi?id=16995 Issue ID: 16995 Summary: __traits(getUnittests) doesn't work with separate compilation Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 20 December 2016 at 01:06:01 UTC, Andrei Alexandrescu wrote: Pushed again, now with the syntax using "with" proposed by Hatem Oraby and others. https://github.com/dlang/DIPs/pull/51 https://github.com/dlang/DIPs/blob/71bde077488b566fba7603de6095b45984d9294a/DIPs/DIP1005.md

[Issue 16783] std.net.curl application throws an exception

https://issues.dlang.org/show_bug.cgi?id=16783 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |RESOLVED

Re: DIP10005: Dependency-Carrying Declarations is now available for community feedback

On Tuesday, 20 December 2016 at 14:31:38 UTC, Dmitry Olshansky wrote: On 12/13/16 11:33 PM, Andrei Alexandrescu wrote: Destroy. https://github.com/dlang/DIPs/pull/51/files Andrei Just a thought but with all of proliferation of imports down to each declaration comes the pain that e.g.

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 17:28:49 UTC, Stefan Koch wrote: On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko wrote: Are they already CTFEable? I have not seen an anounce, sorry They have been for years now. Of course only pointers from a CTFE context are valid at ctfe. The

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko wrote: Are they already CTFEable? I have not seen an anounce, sorry They have been for years now. Of course only pointers from a CTFE context are valid at ctfe. The new engine will support them as well, (as it will eventually

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 17:05:03 UTC, Stefan Koch wrote: On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You

[Issue 16573] string-typed enum values pass isSomeString but not isInputRange

https://issues.dlang.org/show_bug.cgi?id=16573 --- Comment #5 from r...@rcorre.net --- (In reply to RazvanN from comment #4) > This should be closed, right? I don't know when things get transitioned from fixed to closed, but a fix has been merged to master:

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright wrote: On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer. Ranges a

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe The way to make this useful, if I'm understanding correctly, would not be a more concise

Re: CTFE Status

Hey Guys I wanted to give a quick update. I recently fixed an interesting bug that happened de-referencing null pointers to the heap. That would cause arrays to be overwritten, when passed as arguments. That bug had me stuck for a few hours. Getting Function-Calls right will be impossible,

Re: Multiple return value as requirements for safety and performance

On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote: No, tuples stores either value or pointer. If it stores pointer then it is not safe and it is not CTFE. You can make it safe by using an array rather than a pointer.

Re: D future ...

On 12/20/2016 7:44 AM, bachmeier wrote: On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote: If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find. This is a valid point. I just did that for some std.datetime functions that need

Re: D future ...

On 12/20/2016 7:17 AM, Benjiro wrote: I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Oh, it's certainly there. If you want to change C++ or the C++ Standard Library, you are told to submit a proposal paper to

[Issue 16994] New: Apparently faulty symbol resolution in some cases

https://issues.dlang.org/show_bug.cgi?id=16994 Issue ID: 16994 Summary: Apparently faulty symbol resolution in some cases Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: major

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 16:06:49 UTC, Ilya Yaroshenko wrote: On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:50:03 UTC, Nordlöw wrote: On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe Do pointers worsen

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:40:57 UTC, Nordlöw wrote: DIP-32 has been dormant since 2013. I've been waiting for builtin tuples ever since I started using D. I wonder if it might be possible to add the tuple syntax incrementally into DMD? It's always easier to approve something less

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:42:52 UTC, Ilya Yaroshenko wrote: This thread is about mutiple values returned by _reference_. Tuples can not do it, only pointers, but they are not ctfeable and safe Do pointers worsen performance aswell? Even when using LDC?

Re: D future ...

On Tuesday, 20 December 2016 at 11:52:05 UTC, Walter Bright wrote: If you don't want to fix anything, ok. But you can still file bugzilla issues for things that you find. This is a valid point. I just did that for some std.datetime functions that need improved documentation.

Re: D future ...

On 12/20/2016 05:17 PM, Benjiro wrote: > On Tuesday, 20 December 2016 at 14:09:45 UTC, Dibyendu Majumdar wrote: >> >> Apologies for being one of those who offers advice but no action. > > Don't be Dibyendu ... > > We "ranters" are actually D's "client base". There seem to be the wrong >

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 15:36:27 UTC, jmh530 wrote: On Tuesday, 20 December 2016 at 14:56:37 UTC, Ilya Yaroshenko wrote: As you can see the output should be 1000, but it is 1. I was a little confused by what you meant, but the following main is a little more obvious to me void

Re: D future ...

On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote: I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Its mostly on the smaller languages where they lack people. And at the same time, that is a very scary

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 13:47:50 UTC, Ilya Yaroshenko wrote: One good thing for safety and CTFE is allow multiple return value. In combination with `auto ref` it is _very_ powerful: auto ref front() { // Returns 2 values, each value is returned by reference if possible return

Re: D future ...

On Tuesday, 20 December 2016 at 10:46:28 UTC, bachmeier wrote: I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation. Many of the top folks don't use it, but I recall Andre commenting on trying to use it and getting frustrated. It's

Re: Multiple return value as requirements for safety and performance

On Tuesday, 20 December 2016 at 14:56:37 UTC, Ilya Yaroshenko wrote: As you can see the output should be 1000, but it is 1. I was a little confused by what you meant, but the following main is a little more obvious to me void main() { auto c = front(); c[0] = 1000;

[Issue 16993] New: Documentation for toSimpleString and toString does not explain how they differ

https://issues.dlang.org/show_bug.cgi?id=16993 Issue ID: 16993 Summary: Documentation for toSimpleString and toString does not explain how they differ Product: D Version: D2 Hardware: All OS: All

Re: BetterC classes

On Tuesday, 20 December 2016 at 13:30:54 UTC, Kagamin wrote: On Friday, 16 December 2016 at 18:29:33 UTC, Ilya Yaroshenko wrote: Undefined symbols for architecture x86_64: "__D14TypeInfo_Class6__vtblZ", referenced from: __D8cppclass2Hw7__ClassZ in cppclass-7ed89bd.o By using typeid

  1   2   >