Re: Move construction from !is(T == typeof(this))

On Tuesday, 25 April 2017 at 01:59:55 UTC, Manu wrote: Ah crap, I somehow missed the single-argument move() function. Okay, so this pattern is definitely reliable? I haven't seen it clearly documented anywhere that this is the prescribed pattern, and it's come up on stack overflow a few

Re: excel-d v0.0.1 - D API to write functions callable from Excel

C++ example for XLW: LPXLFOPER EXCEL_EXPORT xlStats(LPXLFOPER inTargetRange) { EXCEL_BEGIN; XlfOper xlTargetRange(inTargetRange); // Temporary variables. double averageTmp = 0.0; double varianceTmp = 0.0; // Iterate over the cells in the

Re: excel-d v0.0.1 - D API to write functions callable from Excel

On Monday, 24 April 2017 at 21:59:34 UTC, Atila Neves wrote: Now with more `@nogc`. Before, this worked fine: double func(double d) @nogc nothrow { return d * 2; } The function is `@nogc`, the wrapper function (i.e. the function that Excel actually calls) is also `@nogc` via the magic of

Re: Move construction from !is(T == typeof(this))

On 25 April 2017 at 08:46, Andrei Alexandrescu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 04/24/2017 04:23 PM, ag0aep6g wrote: > >> On 04/24/2017 08:48 PM, Stanislav Blinov wrote: >> >>> Speaking of const violation and UB, std.algorithm.mutation.move seems to >>> violate const

Re: Move construction from !is(T == typeof(this))

On 04/24/2017 07:13 PM, Stanislav Blinov wrote: On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu wrote: On 04/24/2017 04:23 PM, ag0aep6g wrote: On 04/24/2017 08:48 PM, Stanislav Blinov wrote: Speaking of const violation and UB, std.algorithm.mutation.move seems to violate const

[Issue 15315] can break immutable with std.algorithm.move

https://issues.dlang.org/show_bug.cgi?id=15315 --- Comment #3 from Andrei Alexandrescu --- Indeed, apologies. The target cannot be immutable. --

[Issue 15315] can break immutable with std.algorithm.move

https://issues.dlang.org/show_bug.cgi?id=15315 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 22:46:18 UTC, Andrei Alexandrescu wrote: On 04/24/2017 04:23 PM, ag0aep6g wrote: On 04/24/2017 08:48 PM, Stanislav Blinov wrote: Speaking of const violation and UB, std.algorithm.mutation.move seems to violate const without remorse: Yup. Even in @safe code, which

Re: Move construction from !is(T == typeof(this))

On 04/24/2017 04:23 PM, ag0aep6g wrote: On 04/24/2017 08:48 PM, Stanislav Blinov wrote: Speaking of const violation and UB, std.algorithm.mutation.move seems to violate const without remorse: Yup. Even in @safe code, which is a bug. https://issues.dlang.org/show_bug.cgi?id=15315 Should fail

[Issue 15315] can break immutable with std.algorithm.move

https://issues.dlang.org/show_bug.cgi?id=15315 Andrei Alexandrescu changed: What|Removed |Added CC||and...@erdani.com

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts

Re: DIP 1007 Preliminary Review Round 1

On Monday, 24 April 2017 at 15:22:15 UTC, Ola Fosheim Grøstad wrote: On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote: DIP 1007 is titled "'future symbol' Compiler Concept". «In all the mentioned languages but D, a common convention is to only use unqualified access for symbols in

Re: excel-d v0.0.1 - D API to write functions callable from Excel

On Monday, 20 March 2017 at 20:09:58 UTC, Atila Neves wrote: http://code.dlang.org/packages/excel-d This dub package allows D code to be called from Excel. It uses compile-time reflection to register the user's code in an XLL (a DLL loaded by Excel) so no boilerplate is necessary. Not even

Re: Algebra With Types

On Friday, 21 April 2017 at 20:49:27 UTC, Meta wrote: On Friday, 21 April 2017 at 18:54:38 UTC, David Sanders wrote: [...] As an aside, there's a less convoluted way to do type-level arithmetic which is IMO also more concise and looks nicer. You don't have to mess around with Algebraic at

Re: Address of UFCS call implicity converts to Delegate

On Monday, 24 April 2017 at 19:19:27 UTC, Meta wrote: On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote: I've added a DIP for this (https://github.com/dlang/DIPs/pull/61). At first I first thought that all we needed was to add semantics to take the address of a UFCS-style call,

Re: Move construction from !is(T == typeof(this))

On 04/24/2017 08:48 PM, Stanislav Blinov wrote: Speaking of const violation and UB, std.algorithm.mutation.move seems to violate const without remorse: Yup. Even in @safe code, which is a bug. https://issues.dlang.org/show_bug.cgi?id=15315

[Issue 17346] Inconsistent l/rvalue overload resolution

https://issues.dlang.org/show_bug.cgi?id=17346 Steven Schveighoffer changed: What|Removed |Added CC|

[Issue 15315] can break immutable with std.algorithm.move

https://issues.dlang.org/show_bug.cgi?id=15315 ag0ae...@gmail.com changed: What|Removed |Added Keywords||safe --

Re: Move construction from !is(T == typeof(this))

On 4/24/17 2:48 PM, Stanislav Blinov wrote: On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote: If you're going to pinch the guts of rvalue arguments, then this needs to be 100% reliable. This needs to be aggressively unit-tested, and probably documented that this is the official pattern for

Re: COM Expertise needed: COM Callbacks

On Monday, 24 April 2017 at 17:31:09 UTC, MGW wrote: On Monday, 24 April 2017 at 00:55:45 UTC, Nierjerson wrote: Still trying to get the com automation code working. This is a Please, use ZIP for archive. http://s000.tinyupload.com/index.php?file_id=67286353487198133918

Re: Address of UFCS call implicity converts to Delegate

On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote: I've added a DIP for this (https://github.com/dlang/DIPs/pull/61). At first I first thought that all we needed was to add semantics to take the address of a UFCS-style call, but after messing around with your example I realized

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 15:19:29 UTC, Manu wrote: If you're going to pinch the guts of rvalue arguments, then this needs to be 100% reliable. This needs to be aggressively unit-tested, and probably documented that this is the official pattern for rvalue construction/assignment

Re: Vibed + osv.io

On 4/24/17 5:17 PM, Suliman wrote: On Monday, 24 April 2017 at 15:10:29 UTC, Suliman wrote: I have found very interesting project http://osv.io Has anybody to use it with vibed? I am not sure if it's yet-another-linux distrib or OS written from scratch. As they mention it from the get go -

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote: On 04/24/2017 11:17 AM, Timon Gehr wrote: Also, Java's type system is unsound. Not doubting you, but this sounds interesting. Further info or links? https://dev.to/rosstate/java-is-unsound-the-industry-perspective

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Monday, 24 April 2017 at 11:29:01 UTC, Ola Fosheim Grøstad wrote: What are scaled loads? x86 has addressing modes which allow you to multiply an index by a certain set of scalars and add it as on offset to the pointer you want to load. Thereby making memory access patterns more

Re: COM Expertise needed: COM Callbacks

On Monday, 24 April 2017 at 00:55:45 UTC, Nierjerson wrote: Still trying to get the com automation code working. This is a Please, use ZIP for archive.

Re: Address of UFCS call implicity converts to Delegate

On Monday, 24 April 2017 at 15:47:14 UTC, Jonathan Marler wrote: On Sunday, 23 April 2017 at 17:13:31 UTC, Basile B. wrote: [...] I've added a DIP for this (https://github.com/dlang/DIPs/pull/61). At first I first thought that all we needed was to add semantics to take the address of a

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Monday, 24 April 2017 at 14:41:44 UTC, jmh530 wrote: On Monday, 24 April 2017 at 12:59:55 UTC, Jonathan Marler wrote: Have you considered using the LLVM jit compiler for CTFE? We already have an LLVM front end. This would mean that CTFE would depend on LLVM, which is a large dependency,

Re: GC: Understanding potential sources of false pointers

On 04/22/2017 08:56 AM, Kagamin wrote: .rdata is fine, but afaik you have only strings there, the rest - .data, .bss, .tls will suffer the same issue. I don't know anything about the various object file sections. :/

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On 04/24/2017 11:17 AM, Timon Gehr wrote: Also, Java's type system is unsound. Not doubting you, but this sounds interesting. Further info or links?

Re: multiple `alias this` suggestion

On Friday, 21 April 2017 at 14:51:42 UTC, Meta wrote: auto x = top(1,2,3); void takesMember1(member1) {} void takesMember2(member2) {} void takesMember3(member3) {} static assert(__traits(compiles, { takesMember1(x); })); //Passes static assert(__traits(compiles, { takesMember2(x); }));

Re: multiple `alias this` suggestion

On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote: I agree, I like how this solves the ambiguity problem nicely. However, this disallows using introspection to declare multiple alias this piecemeal. e.g.: struct S(bool foo) { int x; alias x this; static if(foo) {

How to overload member function pointer and a regualr member function

I would like to have this kind of struct: struct Foo { private int i; void function( int i, float f ) bar; // will be defined at runtime void bar( float f ) { bar( i, f ); } } But apparently the function pointer and the member function cannot have the same name: Error: function

[Issue 17347] DMD generates different (and wrong) output in -release mode

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

[Issue 15538] wrong code with switch

https://issues.dlang.org/show_bug.cgi?id=15538 ag0ae...@gmail.com changed: What|Removed |Added CC||alexander.brec...@gmail.com --- Comment

Re: DIP 1007 Preliminary Review Round 1

On 24/04/2017 4:03 PM, Mike Parker wrote: DIP 1007 is titled "'future symbol' Compiler Concept". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period,

[Issue 17347] New: DMD generates different (and wrong) output in -release mode

https://issues.dlang.org/show_bug.cgi?id=17347 Issue ID: 17347 Summary: DMD generates different (and wrong) output in -release mode Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: Address of UFCS call implicity converts to Delegate

On Sunday, 23 April 2017 at 17:13:31 UTC, Basile B. wrote: On Sunday, 23 April 2017 at 17:07:51 UTC, Jonathan Marler wrote: On Sunday, 23 April 2017 at 17:00:59 UTC, Basile B. wrote: 2/ Why not just a member function ? For the same reason that UFCS exists. You can't add "member functions"

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On Monday, 24 April 2017 at 15:17:18 UTC, Timon Gehr wrote: Swift allows raw pointer manipulation. I didn't know that Swift had that as a language construct. Link? I know that it provides library solutions for raw pointers, but that can be said for most languages. Java implementations

Re: DIP 1007 Preliminary Review Round 1

On Monday, 24 April 2017 at 15:03:53 UTC, Mike Parker wrote: DIP 1007 is titled "'future symbol' Compiler Concept". «In all the mentioned languages but D, a common convention is to only use unqualified access for symbols in the standard library.» Not quite right for C++. The common

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On 24.04.2017 13:33, Ola Fosheim Grøstad wrote: On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's

Re: DIP 1007 Preliminary Review Round 1

On Monday, 24 April 2017 at 15:14:44 UTC, Mike Parker wrote: DIP 1006 is titled "'future symbol' Compiler Concept". This Apologies, this is DIP 1007, not 1006.

Re: Vibed + osv.io

On Monday, 24 April 2017 at 15:10:29 UTC, Suliman wrote: I have found very interesting project http://osv.io Has anybody to use it with vibed? I am not sure if it's yet-another-linux distrib or OS written from scratch. I found link on Redox page https://github.com/redox-os/redox/issues/925

Re: Move construction from !is(T == typeof(this))

On 25 April 2017 at 00:00, Steven Schveighoffer via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote: > > I wonder if this overload set could be made to work such that it is >> certain that the non-ref overload is only called with rvalues;

DIP 1007 Preliminary Review Round 1

DIP 1006 is titled "'future symbol' Compiler Concept". This announcement kicks off the first round of preliminary reviews. The review thread can be found in the General forum at: http://forum.dlang.org/post/hjdstwzhcbrektlij...@forum.dlang.org Please also remember that the first preliminary

Vibed + osv.io

I have found very interesting project http://osv.io Has anybody to use it with vibed? I am not sure if it's yet-another-linux distrib or OS written from scratch. I found link on Redox page https://github.com/redox-os/redox/issues/925 It would be nice to have way to get run vibed from

DIP 1007 Preliminary Review Round 1

DIP 1007 is titled "'future symbol' Compiler Concept". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1007.md All review-related feedback on and discussion of the DIP should occur in this thread. Due to DConf taking place during the review period, the period will be extended by a week. The

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 13:18:41 UTC, Manu wrote: I've done that too, but that's a seriously shit solution. You didn't comment on any of my actual questions ;) It answered your first question :)

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Monday, 24 April 2017 at 12:59:55 UTC, Jonathan Marler wrote: Have you considered using the LLVM jit compiler for CTFE? We already have an LLVM front end. This would mean that CTFE would depend on LLVM, which is a large dependency, but it would create very fast, optimized code for CTFE on

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote: struct X {} struct Y { this(auto ref X x) { static if (__traits(isRef, x)) { // x is lvalue, copy construct } else { // x MUST be rvalue(?), move construct // does this pattern require that I

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 14:00:33 UTC, Steven Schveighoffer wrote: On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote: I wonder if this overload set could be made to work such that it is certain that the non-ref overload is only called with rvalues; ie, given this ambiguous call, ref is

[Issue 17346] New: Inconsistent l/rvalue overload resolution

https://issues.dlang.org/show_bug.cgi?id=17346 Issue ID: 17346 Summary: Inconsistent l/rvalue overload resolution Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal

Re: Move construction from !is(T == typeof(this))

On 4/24/17 12:21 AM, Manu via Digitalmars-d wrote: I wonder if this overload set could be made to work such that it is certain that the non-ref overload is only called with rvalues; ie, given this ambiguous call, ref is preferred for lvalues. rval can not call ref, therefore must resolve to

Re: Move construction from !is(T == typeof(this))

On 24 April 2017 at 18:36, Ola Fosheim Grøstad via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote: > >> Now, I'm not saying that rval references are the only solution here, just >> that I can overload the construction from an X for the

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Thursday, 20 April 2017 at 12:56:11 UTC, Stefan Koch wrote: Hi Guys, I just begun work on the x86 jit backend. Because right now I am at a stage where further design decisions need to be made and those decisions need to be informed by how a _fast_ jit-compatible x86-codegen is

Re: The app hanging after reach 1750MB of RAM

The problem is solved. See for more detail https://github.com/mysql-d/mysql-native/issues/104

Re: Why need dep 32 bit library?!

On Monday, 24 April 2017 at 12:13:41 UTC, Basile B. wrote: On Monday, 24 April 2017 at 11:40:04 UTC, Brian wrote: [...] Does DMD works with -ivh --force ? Sorry I meant: if you install with these options.

Re: Why need dep 32 bit library?!

On Monday, 24 April 2017 at 11:40:04 UTC, Brian wrote: OH ... NO ... I want install dmd to my fedora 26, but I get 64bit dmd's rpm package notic info: [root@fedora Downloads]# rpm -ivh dmd-2.074.0-0.fedora.x86_64.rpm error: Failed dependencies: glibc-devel(x86-32) is needed by

Re: Why need dep 32 bit library?!

Install very large deps 32bit libs . [root@fedora Downloads]# dnf install glibc-devel.i686 libcurl.i686 libgcc.i686 Last metadata expiration check: 2:16:19 ago on Mon Apr 24 17:30:50 2017 CST. Dependencies resolved.

Why need dep 32 bit library?!

OH ... NO ... I want install dmd to my fedora 26, but I get 64bit dmd's rpm package notic info: [root@fedora Downloads]# rpm -ivh dmd-2.074.0-0.fedora.x86_64.rpm error: Failed dependencies: glibc-devel(x86-32) is needed by dmd-2.074.0-0.x86_64 libcurl(x86-32) is needed by

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as

Re: {OT} Youtube Video: newCTFE: Starting to write the x86 JIT

On Saturday, 22 April 2017 at 14:29:22 UTC, Stefan Koch wrote: And for that reason I am looking to extend the interface to support for example scaled loads and the like. Otherwise you and up with 1000 temporaries that add offsets to pointers. What are scaled loads? Also and perhaps more

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

On Friday, 21 April 2017 at 17:20:14 UTC, Vasudev Ram wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means: what are D developers generally called (to indicate that they develop in D)? The question occurred to me somehow while browsing some D posts

Re: Compare boost::hana to D

On Saturday, 22 April 2017 at 07:53:49 UTC, Johannes Pfau wrote: OT but is there any benefit to identify events with strings? As long as you use compile time only events I'd prefer a syntax as in https://github.com/WebFreak001/EventSystem (one benefit is that it's 100% IDE autocomplete

Re: Compile time foreach with switch

On Saturday, 22 April 2017 at 11:56:31 UTC, Nick Treleaven wrote: If I compile the above I get: Deprecation: switch case fallthrough - use 'goto default;' if intended IMO the compiler should issue this warning with the OP's code. https://issues.dlang.org/show_bug.cgi?id=7390#c4

[Issue 7390] Problem in generating switch cases with a static foreach

https://issues.dlang.org/show_bug.cgi?id=7390 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 04:21:36 UTC, Manu wrote: Now, I'm not saying that rval references are the only solution here, just that I can overload the construction from an X for the rvalue and non-rvalue case, which is what I want... What I've done in the past is simply to create a

Re: Move construction from !is(T == typeof(this))

On Monday, 24 April 2017 at 05:00:13 UTC, rikki cattermole wrote: There is[0] but idk how close it is to std:move and the likes. [0] http://dlang.org/phobos/std_algorithm_mutation.html#.move std::move doesn't do anything, it is just a type-cast.

Re: Move construction from !is(T == typeof(this))

Yeah, that's not the same thing at all. On 24 April 2017 at 15:00, rikki cattermole via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > There is[0] but idk how close it is to std:move and the likes. > > [0] http://dlang.org/phobos/std_algorithm_mutation.html#.move >

Re: Python : Pythonista / Ruby: Rubyist : / D : ?

On Saturday, 22 April 2017 at 17:17:46 UTC, Vasudev Ram wrote: On Saturday, 22 April 2017 at 08:30:03 UTC, Russel Winder wrote: On Fri, 2017-04-21 at 17:20 +, Vasudev Ram via Digitalmars-d wrote: Hi list, I hope the question is self-evident from the message subject. If not, it means:

Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017

On 4/23/2017 5:04 AM, Guillaume Piolat wrote: The rules of leak-free, exception-safe C++11 aren't so hard. - single-owneship for everything, invent fake owner if needed - std::unique_ptr for owning pointer, raw pointers for borrowed (unique_ptr neatly avoids to write a RAII wrapper for

mir.array.primitives and mir.bitmanip were added

Mir release v0.4.12 comes with simple but powerful API additions. mir.array.primitives [1] === Added empty, front, back pop*[N/Exactly], length primitives. Difference with Phobos: 1. Do not break LDC fastmath optimisations. (because they marked @fastmath) This is important for sci