Re: How to call function with variable arguments at runtime?

On Tuesday, 10 October 2017 at 02:58:45 UTC, Mr. Jonse wrote: I need to store a hetrogeneous array of delegates. How can I do this but still call the function with the appropriate number of parameters at run time? I have the parameters as Variant[] params and a function/delegate

Re: GC

On Sunday, 30 July 2017 at 09:12:53 UTC, piotrekg2 wrote: I would like to learn more about GC in D. For example can anyone explain why do we need memset(0) here: https://github.com/dlang/phobos/blob/master/std/container/array.d#L356 , doesn't it assume a certain type of GC? What if there is a

Re: Static array * scalar is not working for me

On Sunday, 30 July 2017 at 08:18:07 UTC, Danni Coy wrote: The following code is not working for me float[3] f; f[] = abs(f)[] * -1.0f; where abs is a function that returns a float[3]; it complains that f should be attached to some memory. Is it a bug or am I missing something? I cannot

Re: proposed @noreturn attribute

On Wednesday, 12 July 2017 at 13:22:46 UTC, Meta wrote: D is not ML or Haskell or Idris. Rust has trod this ground before us and they saw it prudent to not make ! a first-class type. Only to turn around after they realized their mistake:

Re: proposed @noreturn attribute

On Sunday, 16 July 2017 at 20:44:13 UTC, Andrei Alexandrescu wrote: Perhaps we go the inverse route and define the bottom type as typeof(*null). Would that simplify matters? There is some good consistency about it: null: a pointer to anything. But can't be dereferenced. *null: well,

Re: Split Real / Float into Mantissa, Exponent, and Base

On Friday, 3 March 2017 at 18:09:02 UTC, Jonathan M. Wilbur wrote: I have tried to come up with a good way to get the mantissa, exponent, and base from a real number, and I just can't come up with a good cross-platform way of doing it. I know about std.math.frexp(), but that function only

Re: switch to member

You can utilize a little-known `switch` syntax trick in combination with `foreach`. Because a `foreach` over tuples is unrolled at compile time, it works even if your fields don't have exactly the same types: -- struct Foo { int

Re: Bitfields?

On Friday, 30 December 2016 at 13:45:23 UTC, Martin wrote: Are there any C-like bitfields in D? Yes - How can I use them? No - What could be used in their stead? Not built-in, but in the standard library: https://dlang.org/phobos/std_bitmanip.html#.bitfields

Re: Hangs on toStringZ()

On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote: Hello I have very simple line with exec-command: execl("/bin/bash".toStringz(), "/bin/bash".toStringz(), "-c".toStringz(), command.toStringz(), null); And on this line on toStringz my program sometimes hangs. backtrace: (gdb) bt

Re: Complex numbers are harder to use than in C

On Saturday, 19 November 2016 at 20:24:09 UTC, Marduk wrote: On Saturday, 19 November 2016 at 12:55:57 UTC, Marc Schütz wrote: On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote: On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote: The difference is that D is more verbose. Am

Re: Complex numbers are harder to use than in C

On Saturday, 19 November 2016 at 20:08:42 UTC, Marduk wrote: On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote: On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote: The difference is that D is more verbose. Am I missing something? Can we have C's behaviour in D? Something

Re: Complex numbers are harder to use than in C

On Saturday, 19 November 2016 at 11:11:36 UTC, Nordlöw wrote: On Saturday, 19 November 2016 at 09:38:38 UTC, Marduk wrote: The difference is that D is more verbose. Am I missing something? Can we have C's behaviour in D? Something like auto I(T)(T im) if (isNumeric!T) { return

Re: calling convention optimisation & const/immutable ref

On Monday, 7 November 2016 at 16:48:55 UTC, John Colvin wrote: Some people use ref for performance to prevent the copying that must occur when passing by value. I propose a small optimisation to make this unnecessary in a bunch of cases. At the ABI level (no change in language semantics), if

Re: CTFE Status

On Saturday, 5 November 2016 at 01:21:48 UTC, Stefan Koch wrote: I thought about it some more, and decided that I will replace the old interpreter completely in the long run. However in order to get something release before 2017, I have to rely on it being there. That's better of course.

Re: CTFE Status

On Friday, 4 November 2016 at 01:19:36 UTC, Chris Wright wrote: On Thu, 03 Nov 2016 15:44:20 +, Marc Schütz wrote: On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: I intend to keep the current implemntation around as a fallback. For things that are used rarely. like

Re: CTFE Status

On Thursday, 3 November 2016 at 16:35:08 UTC, Stefan Koch wrote: On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote: On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: I intend to keep the current implemntation around as a fallback. For things that are used rarely.

Re: CTFE Status

On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote: I intend to keep the current implemntation around as a fallback. For things that are used rarely. like floating point and others :) Is that a good idea? It means that there will be tons of really complex code that is rarely if

Re: Best approach to handle accented letters

On Friday, 28 October 2016 at 11:24:28 UTC, Alfred Newman wrote: Hello, I'm getting some troubles to replace the accented letters in a given string with their unaccented counterparts. Let's say I have the following input string "très élégant" and I need to create a function to return just

Re: "for" statement issue

On Friday, 21 October 2016 at 13:42:49 UTC, Adam D. Ruppe wrote: On Friday, 21 October 2016 at 13:33:26 UTC, Stefan Koch wrote: It does create a lambda? Hmm that should not happen. Eh, that's exactly what the language rules say should happen, and it actually does make sense to me... you

Re: weighted round robin

On Tuesday, 18 October 2016 at 16:43:19 UTC, vino wrote: On Wednesday, 12 October 2016 at 13:44:59 UTC, Erikvv wrote: In your first post you mention it should be weighted, but I see no weights anywhere. Hi Marc, I am at the initial stage of implementing the round robin algorithm and still

Re: Determining if a class has a template function

On Wednesday, 12 October 2016 at 16:57:50 UTC, Meta wrote: There's also a *very* ugly hack you can do: //A template function's .stringof is of the format name>()() //so match on the number of brackets to determine whether it's a template function or not enum isTemplateFunction =

Re: opIndexDispatch?

On Thursday, 13 October 2016 at 01:09:06 UTC, Ali Çehreli wrote: On 10/10/2016 12:01 PM, Yuxuan Shui wrote: Hi, Why is there no opIndexDispatch for overloading a[x].func() ? I could not understand the question fully but would using an element proxy work? I assume a proxy would indeed

Re: isRvalue trait

On Monday, 10 October 2016 at 11:46:01 UTC, Nordlöw wrote: At https://github.com/nordlow/phobos-next/blob/master/src/moval.d I've implemented a helper function for creating r-value out of l-values defined as E movedToRvalue(E)(ref E e) { import std.algorithm.mutation : move; E

Re: weighted round robin

On Saturday, 8 October 2016 at 22:48:53 UTC, vino wrote: Hi, Can some one guide me on how to implement the weighted round robin, below is what i tried or any other better ways to do it Main Requirement : Incoming socket connection has to be sent to 3 servers in the weighted round robin

Re: DIP 1002 (TryElseExpression) added to the queue

On Thursday, 29 September 2016 at 17:47:41 UTC, Walter Bright wrote: On 9/29/2016 4:45 AM, Marc Schütz wrote: And `Foo` could have `@disabled this()`, so you simply _can't_ declare it without initializing it Foo foo = void; That's even worse. At least Foo.init would be deterministic.

Re: Explicit casting of enum -- intentional restriction?

On Saturday, 1 October 2016 at 20:52:48 UTC, rcorre wrote: I just tried to compile an old project and the following failed: --- enum Paths : string { bitmapDir = "content/image", fontDir = "content/font", soundDir = "content/sound", ... if (Paths.preferences.exists)

Re: "Disappearing" operator methods

Please have a look at this PR: https://github.com/dlang/dmd/pull/6140 However, the error message printed with this PR isn't particularly helpful either: Error: incompatible types for ((5) in (m2)): 'int' and 'const(MyTable)' You might want to add a comment there, and/or open an enhancement

Re: DIP 1002 (TryElseExpression) added to the queue

On Wednesday, 28 September 2016 at 22:12:27 UTC, Idan Arye wrote: Foo foo; try { foo = Foo(); } catch (FooCreationException) { // ... } else { foo.doSomethingWithFoo(); } // foo exists here - it could be initialized, it could be not... And `Foo`

Re: Required DMD changes for Mir and few thoughts about D future

On Thursday, 29 September 2016 at 09:22:56 UTC, Martin Nowak wrote: On Monday, 26 September 2016 at 22:34:59 UTC, Andrei Alexandrescu wrote: That would work out as long as interaction is seamless. Please advise. Overall: I think Ilya's work can make a real difference for D, and we can't afford

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 14:57:26 UTC, Dsciple wrote: struct ConfigParams { // ... // Define configuration parameters' static default fields static immutable BindAddresses defaultBindAddresses = BindAddresses([ BindAddress("192.168.2.10") ]); // ... } Yepp, that's

Re: Problem parsing IPv4/IPv6 addresses with std.socket.parseAddress

On Tuesday, 27 September 2016 at 09:04:53 UTC, Dsciple wrote: As said, this works fine when tested in isolation, and the compiler only complains when using BindAddress as a member of ConfigParams. Any idea what the problem may be? Or is there maybe a ready to use, high-level library for

Re: thisExePath purity

On Tuesday, 20 September 2016 at 04:17:21 UTC, crimaniak wrote: Hi and thanks all! On Tuesday, 20 September 2016 at 00:43:10 UTC, Jonathan M Davis wrote: immutable string executablePath; shared static this() { import std.file : thisExePath(); executablePath = thisExePath(); }

Re: Fiber Concurrency Showcase

On Tuesday, 13 September 2016 at 10:02:28 UTC, Andrea Fontana wrote: On Tuesday, 13 September 2016 at 09:46:46 UTC, Nordlöw wrote: I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for

Re: Fiber Concurrency Showcase

On Tuesday, 13 September 2016 at 09:46:46 UTC, Nordlöw wrote: I would like to experiment with Fibers/Coroutines in D/vibe.d. I'm missing a code example in std.concurrency that highlights an example of using Fibers for massive concurrency. Could anybody show me such a code example or link to a

Re: DIP1001: DoExpression

On Tuesday, 6 September 2016 at 17:01:28 UTC, Timon Gehr wrote: There can be no field (or variables) of type 'void'. (void,void,T) has two fields of type 'void'. Just fixing the limitations is also not really possible, as e.g. void* and void[] exploit that 'void' is special and have a

Re: Taking pipeline processing to the next level

On Wednesday, 7 September 2016 at 10:31:13 UTC, finalpatch wrote: I think the problem here is two fold. First question, how do we combine pipeline stages with minimal overhead I think the key to this problem is reliable *forceinline* for example, a pipeline like this

Re: ADL

On Saturday, 3 September 2016 at 11:24:01 UTC, Walter Bright wrote: On 9/3/2016 3:12 AM, Walter Bright wrote: If you are still determined to use it, you can use: __traits(compiles, ...) like you would SFINAE in C++ to select which of the modules from the argument types selects a function

Re: Low level unit test library in druntime

On Tuesday, 30 August 2016 at 15:45:26 UTC, Andrei Alexandrescu wrote: On 08/30/2016 10:44 AM, Atila Neves wrote: I'd much rather have `assert` be magical or have AST macros to make the syntax for writing tests better than what it is now. Same here. BTW I'd like unittests that "must not

Re: Fact checking for my talk

On Saturday, 13 August 2016 at 12:47:40 UTC, Ethan Watson wrote: | Rust | Swift |C# | -|-+-+-| Template Constraints |Y|Y| where | [1]

Re: DIP1000: Scoped Pointers

On Thursday, 11 August 2016 at 22:03:02 UTC, Walter Bright wrote: On 8/11/2016 6:38 AM, Sönke Ludwig wrote: What would be nice to add is a behavior specification for 'scope' member variables (lifetime considered equal or slightly shorter than parent object lifetime). For example the

Re: DIP1000: Scoped Pointers (Discussion)

My comments: 1) `scope` on local variables is unnecessary. Requiring it probably makes the implementation easier, but it doesn't need to be specified explicitly because it can always be inferred. It's a tradeoff: do we want to make it easier for compiler writers to implement, or do we want

Re: How to group similar member functions from different classes?

On Friday, 15 July 2016 at 17:25:23 UTC, cy wrote: On Monday, 20 June 2016 at 16:39:54 UTC, Marc Schütz wrote: Untested: Seems to only work if A and B are both defined in the same file as Foos (defeating the purpose). Putting A and B in a.d and b.d respectively gives me these errors:

Re: local const functions - bug ?

On Sunday, 10 July 2016 at 07:20:29 UTC, Meta wrote: On Friday, 8 July 2016 at 09:01:10 UTC, Marc Schütz wrote: `foo()` is effectively a delegate, therefore `const` applies to the context. AFAIK const on a function can only ever refer to the `this` pointer, but there is no `this` pointer.

Re: local const functions - bug ?

On Thursday, 7 July 2016 at 15:02:29 UTC, Jonathan M Davis wrote: On Thursday, July 07, 2016 10:33:39 Basile B. via Digitalmars-d-learn wrote: this compiles without error: struct Foo { int i; void bar() { void foo() const { i = 1; }

Re: Initializing static array with contents of (static and dynamic) arrays

auto concat(T : E[n], E, size_t n)(const E[][] args...) @nogc { size_t offset = 0; T result = void; foreach(arr; args) { result[offset .. offset+arr.length] = arr; offset += arr.length; } assert(offset == result.length); return result; } static immutable

Re: Is there anyway to make opApply @nogc?

On Tuesday, 21 June 2016 at 19:21:01 UTC, Gary Willoughby wrote: Right ok, thanks! It doesn't seem to help though as the compiler complains about it being not @nogc. You probably need to declare the delegate and opApply() itself as @nogc, too: int opApply(scope int delegate(int) @nogc dg)

Re: How to group similar member functions from different classes?

Untested: // foo.d import a, b; mixin template Foos { static if(is(typeof(this) == A)) void foo() { /* implementation for A */ } static if(is(typeof(this) == B)) void foo() { /* implementation for B */ } } // a.d import foo; class A { mixin Foos; } // b.d import foo; class

Re: Error: castSwitch

On Tuesday, 7 June 2016 at 03:55:03 UTC, none wrote: import std.algorithm.iteration : map; import std.algorithm : castSwitch; import std.format : format; class A { int value; this(int value) { this.value = value; }} interface I { } class B : I { } Object[] arr = [new A(5), new

Re: Beta release DUB 1.0.0-beta.1

On Tuesday, 7 June 2016 at 09:54:19 UTC, Sönke Ludwig wrote: DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support for single-file packages, which can be used to write shebang-style scripts on Posix systems: #!/usr/bin/env dub /++ dub.sdl: name "colortest"

Re: Lifetime tracking

On Thursday, 2 June 2016 at 23:29:57 UTC, Timon Gehr wrote: void foo(scope int* k){ void bar(){ scope int* x; // need to check that lifetime of x ends not after lifetime of k assign(x,k); } } I.e. now we need a way to annotate 'assign' in order to specify

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 14:28:44 UTC, Andrei Alexandrescu wrote: That's not going to work. A false impression created in this thread has been that code points are useless They _are_ useless for almost anything you can do with strings. The only places where they should be used are std.uni

Re: The Case Against Autodecode

On Thursday, 2 June 2016 at 13:11:10 UTC, Steven Schveighoffer wrote: On 6/1/16 6:31 AM, Marc Schütz wrote: I believe everything that does only concatenation will work correctly. That's why joiner() is one of those algorithms that should accept strings directly without going through any

Re: The Case Against Autodecode

On Wednesday, 1 June 2016 at 14:29:58 UTC, Andrei Alexandrescu wrote: On 06/01/2016 06:25 AM, Marc Schütz wrote: On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote: The point is to operate on representation-independent entities (Unicode code points) instead of low-level

Re: opCall override default constructor?

On Thursday, 2 June 2016 at 08:50:26 UTC, Jacob Carlborg wrote: Is it intentional that a non-static opCall overrides the default constructor of a struct? struct Foo { int a; void opCall(string b) { } } void main() { auto f = Foo(3); // line 14 f("asd"); } The above code

Re: The Case Against Autodecode

On Wednesday, 1 June 2016 at 01:13:17 UTC, Steven Schveighoffer wrote: On 5/31/16 4:38 PM, Timon Gehr wrote: What about e.g. joiner? Compiler error. Better than what it does now. I believe everything that does only concatenation will work correctly. That's why joiner() is one of those

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote: On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote: Wasn't the whole point of operating at the code point level by default to make it so that code would be operating on full characters by default instead of

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 20:56:43 UTC, Andrei Alexandrescu wrote: On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote: In the vast majority of cases what folks care about is full character How are you so sure? -- Andrei He doesn't need to be sure. You are the one advocating

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 16:29:33 UTC, Joakim wrote: UTF-8 is an antiquated hack that needs to be eradicated. It forces all other languages than English to be twice as long, for no good reason, have fun with that when you're downloading text on a 2G connection in the developing world. I

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 21:51:36 UTC, Walter Bright wrote: On 5/30/2016 8:34 AM, Marc Schütz wrote: In an ideal world, we'd also want to change the way `length` and `opIndex` work, Why? strings are arrays of code units. So, strings are _implemented_ as arrays of code units. But

Re: Why do some T.init evaluate to true while others to false?

On Monday, 30 May 2016 at 19:06:53 UTC, ArturG wrote: does this count? struct Foo { int x; float f; } void main() { Foo foo; if(foo is typeof(foo).init) "A: does'nt work".writeln; foo = Foo(); if(foo is typeof(foo).init) "B: works".writeln; } This one is a bug in DMD.

Re: The Case Against Autodecode

On Monday, 30 May 2016 at 14:56:36 UTC, ag0aep6g wrote: All this is only sensible when we move to a dedicated string type that's not just an alias of `immutable(char)[]`. `immutable(char)[]` explicitly is an array of code units. It would not be acceptable, in my opinion, if the normal array

Re: Operator overloading through UFCS doesn't work

On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: On Friday, May 27, 2016 09:08:20 Marc Schütz via Digitalmars-d-learn wrote: On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: > The difference is that it's impossible to do > 10.opBinary!"+"(1

Re: The Case Against Autodecode

On Saturday, 28 May 2016 at 12:04:20 UTC, Andrei Alexandrescu wrote: On 5/28/16 6:59 AM, Marc Schütz wrote: The fundamental problem is choosing one of those possibilities over the others without knowing what the user actually wants, which is what both BEFORE and AFTER do. OK, that's a fair

Re: aliasing expressions and identifiers

On Sunday, 29 May 2016 at 14:27:51 UTC, Nick Treleaven wrote: What about if the RCArray (of ref count 1) is assigned to a different one after the local ref is initialised? That is what we're discussing -it's your example above(!) Exactly, and then one of the two suggested approaches will have

Re: Our Sister

On Saturday, 28 May 2016 at 04:28:16 UTC, Manu wrote: On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: It should _safely_ convert to `const(char)[]`. That is not possible, sorry. -- Andrei It should

Re: Our Sister

On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote: On 5/27/16 7:07 AM, Marc Schütz wrote: On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`. That is not possible, sorry.

Re: The Case Against Autodecode

On Friday, 27 May 2016 at 13:34:33 UTC, Andrei Alexandrescu wrote: On 5/27/16 6:56 AM, Marc Schütz wrote: It is not, which has been shown by various posts in this thread. Couldn't quite find strong arguments. Could you please be more explicit on which you found most convincing? -- Andrei

Re: aliasing expressions and identifiers

On Friday, 27 May 2016 at 10:04:14 UTC, Nick Treleaven wrote: On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote: To elaborate: neither `scope` nor reference counting can ever protect you against explicit premature destruction of a still-referenced owner. But there is a slightly

Re: Our Sister

On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote: RFC: what primitives should RCStr have? It should _safely_ convert to `const(char)[]`.

Re: The Case Against Autodecode

On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu wrote: This might be a good time to discuss this a tad further. I'd appreciate if the debate stayed on point going forward. Thanks! My thesis: the D1 design decision to represent strings as char[] was disastrous and probably one of

Re: Why do some T.init evaluate to true while others to false?

On Thursday, 26 May 2016 at 16:45:22 UTC, ArturG wrote: im just playing with this template[1] is there anything else i missed? (if you dont mind) it basically treats any T.init as false and skips the function/delegate and just returns type. [1] https://dpaste.dzfl.pl/d159d83e3167 If you

Re: Testing array ptr for offset 0...

On Thursday, 26 May 2016 at 22:47:02 UTC, Era Scarecrow wrote: On Thursday, 26 May 2016 at 22:15:42 UTC, ag0aep6g wrote: Sorry, I'm still lost. Why can't you do whatever you're doing in opOpAssign directly there, or in a free function? Does the pseudo-array contain any additional data? Would a

Re: Operator overloading through UFCS doesn't work

On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: The difference is that it's impossible to do 10.opBinary!"+"(15), so if you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict, it won't work with built-in types. Well, that begs the question: Why don't

Re: full copies on assignment

On Thursday, 26 May 2016 at 10:51:30 UTC, John Nixon wrote: On Wednesday, 25 May 2016 at 15:44:34 UTC, Marc Schütz wrote: On Tuesday, 24 May 2016 at 20:58:11 UTC, John Nixon wrote: On Tuesday, 24 May 2016 at 15:17:37 UTC, Adam D. Ruppe wrote: On Tuesday, 24 May 2016 at 14:29:53 UTC, John

Re: inner functions instead of scope

On Tuesday, 24 May 2016 at 02:01:14 UTC, cy wrote: void transaction(Callable)(Callable do_stuff) `scope` to avoid GC if(isCallable(Callable)) { begin(); scope(failure) rollback(); scope(success) commit(); do_stuff(); }

Re: aliasing expressions and identifiers

On Wednesday, 25 May 2016 at 19:47:06 UTC, Nick Treleaven wrote: On 24/05/2016 14:48, Nick Treleaven wrote: What about: @safe unittest { RCArray!int arr; + arr.length = 1; ref r = arr[0]; arr.destroy; // refcount drops to zero, arr.impl memory freed r++; // writes

Re: aliasing expressions and identifiers

On Tuesday, 24 May 2016 at 13:48:41 UTC, Nick Treleaven wrote: What about: @safe unittest { RCArray!int arr; ref r = arr[0]; arr.destroy; // refcount drops to zero, arr.impl memory freed r++; // writes to unallocated memory } You're calling `destroy`

Re: full copies on assignment

On Tuesday, 24 May 2016 at 20:58:11 UTC, John Nixon wrote: On Tuesday, 24 May 2016 at 15:17:37 UTC, Adam D. Ruppe wrote: On Tuesday, 24 May 2016 at 14:29:53 UTC, John Nixon wrote: This naively doesn’t seem right because the RHS of an assignment should not be altered by it. It's because the

Re: aliasing expressions and identifiers

On Monday, 23 May 2016 at 15:18:51 UTC, Nick Treleaven wrote: On Monday, 23 May 2016 at 14:05:43 UTC, deed wrote: Some thoughts about extending the with-statement were brought up here earlier: http://forum.dlang.org/post/txpifmwpmmhsvcpbc...@forum.dlang.org I don't care much whether it would

Re: mutable keyword

On Sunday, 22 May 2016 at 09:42:54 UTC, Jack Applegame wrote: I agree. But I think we need something that allows *logical* const and immutable. Strict binding constness to physical memory constancy is not always necessary and sometimes even harmful. http://wiki.dlang.org/DIP89

Re: Immutable objects and constructor ?

On Friday, 20 May 2016 at 15:07:53 UTC, chmike wrote: The error message is gone, but I now have another compilation error message I don't understand. This is what I have in fact interface Info { . . . } class MyInfos { . . . protected: class Obj : Info { . . . } public:

Re: DMD producing huge binaries

On Friday, 20 May 2016 at 13:24:42 UTC, Andrei Alexandrescu wrote: I don't see a need for hashing something. Would a randomly-generated string suffice? That would break separate compilation, wouldn't it?

Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests

On Tuesday, 17 May 2016 at 14:22:51 UTC, Meta wrote: On Tuesday, 17 May 2016 at 09:54:15 UTC, Marc Schütz wrote: You surely mean "used to be destroy", right? Good question... If I write this: struct Test { ~this() { writeln("destroying Test"); } } with (Test()) { //Do stuff } Will

Re: unit-threaded v0.6.13 - tags, autotags and support for integration tests

On Monday, 16 May 2016 at 14:39:22 UTC, Meta wrote: On Monday, 16 May 2016 at 08:37:48 UTC, Atila Neves wrote: with(immutable Sandbox()) { writeFile("foo.txt", "foobarbaz\ntoto"); // can also pass string[] for lines shouldExist("foo.txt"); shouldNotExist("bar.txt");

Re: Using shorthand *= leads to unexpected result?

On Sunday, 15 May 2016 at 13:01:45 UTC, Michael wrote: It may be that I'm doing something wrong here, but after updating DMD to the latest version, my simulations started producing some very odd results and I think I've pinpointed it to a sign inversion that I was making. Here is some code

Re: Command line parsing

On Saturday, 14 May 2016 at 04:34:06 UTC, Andrei Alexandrescu wrote: On 5/13/16 2:27 PM, Russel Winder via Digitalmars-d wrote: getopt is a 1970s C solution to the problem of command line parsing. Most programming languages have moved on from getopt and created language-idiomatic solutions to

Re: The Case Against Autodecode

On Friday, 13 May 2016 at 10:38:09 UTC, Jonathan M Davis wrote: Ideally, algorithms would be Unicode aware as appropriate, but the default would be to operate on code units with wrappers to handle decoding by code point or grapheme. Then it's easy to write fast code while still allowing for

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 23:16:23 UTC, H. S. Teoh wrote: Therefore, autodecoding actually only produces intuitively correct results when your string has a 1-to-1 correspondence between grapheme and code point. In general, this is only true for a small subset of languages, mainly a few

Re: The Case Against Autodecode

On Thursday, 12 May 2016 at 20:15:45 UTC, Walter Bright wrote: 7. Autodecode cannot be used with unicode path/filenames, because it is legal (at least on Linux) to have invalid UTF-8 as filenames. It turns out in the wild that pure Unicode is not universal - there's lots of dirty Unicode that

Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.

On Monday, 9 May 2016 at 08:44:53 UTC, Dmitry Olshansky wrote: On 09-May-2016 02:38, Jon D wrote: [...] The only problem is that it should consider multi-codepoint replacements aka full-case folding in Unicode. Otherwise - go ahead and issue a pull request to add special case for < 0x80.

Re: Compiler silently ignores some method overloads

On Tuesday, 10 May 2016 at 22:17:00 UTC, pineapple wrote: On Tuesday, 10 May 2016 at 09:57:11 UTC, pineapple wrote: On Monday, 9 May 2016 at 18:56:15 UTC, Peter Häggman wrote: No problem here (tested with everything in a single module). I can't help more. Front end version ? Well, this is

Re: Setting a list of values

On Monday, 2 May 2016 at 08:46:31 UTC, Ali Çehreli wrote: On 05/01/2016 12:54 PM, Xinok wrote: > On Sunday, 1 May 2016 at 05:42:00 UTC, Ali Çehreli wrote: >> On 04/30/2016 10:05 PM, Joel wrote: >> > This has no effect: >> > _bars.each!(a => { a._plots.fillColor = Color(255, 180, 0); >> }); >> >>

Re: Setting a list of values

On Sunday, 1 May 2016 at 05:42:00 UTC, Ali Çehreli wrote: On 04/30/2016 10:05 PM, Joel wrote: > This has no effect: > _bars.each!(a => { a._plots.fillColor = Color(255, 180, 0); }); This is a common issue especially for people who know lambdas from other languages. :) Your lambda does not do

Re: vibe.d is blocking threads

On Wednesday, 27 April 2016 at 23:30:10 UTC, Nicholas Wilson wrote: On Wednesday, 27 April 2016 at 13:00:29 UTC, RuZzz wrote: Code: import std.concurrency; import core.thread; //import vibe.http.client; // If uncommented this line, the thread "worker" does not start void

Re: With statement extension

On Tuesday, 26 April 2016 at 12:53:49 UTC, deed wrote: Would it be possible to extend current with statement's expressiveness by two lowerings: 1) Alias expression/symbol and replace in macro fashion: with (a : exprA) { /* use a. will be replaced by exprA by compiler. */ } 2) Accept a list

Re: Simple and effective approaches to constraint error messages

On Monday, 25 April 2016 at 17:52:58 UTC, Andrei Alexandrescu wrote: Idea #1: Detect and use CNF, print which clause failed I prefer this one, because it should work without modifying library or user code. Idea #2: Allow custom error messages The basic idea here is to define

Re: final switch and straight integers

On Thursday, 21 April 2016 at 12:45:34 UTC, Steven Schveighoffer wrote: On 4/19/16 6:04 PM, Stefan Koch wrote: On Tuesday, 19 April 2016 at 14:53:18 UTC, Steven Schveighoffer wrote: or we should do away with requiring handling all enum cases. Are you suggesting getting rid of final switch

Re: Shallow copy object when type is know

On Wednesday, 20 April 2016 at 19:58:15 UTC, Tofu Ninja wrote: How does D not have shallow copy? Seems like a very basic functionality... You could implement a `dup()` method. `dup` is already used for shallow copying of arrays, why not reuse it for classes (as a convention)?

Re: [DUB] Does anyone have some time to look at PR #785?

On Tuesday, 19 April 2016 at 06:31:13 UTC, Sönke Ludwig wrote: This is a rather important pull request and the last big milestone for the 1.0.0 release. I'd like to get the next version out shortly, but this PR is sitting idle for over a month now and partially blocks development. It

Re: multithreading profiling

Which platform/OS, dmd version, and command line are you using?

  1   2   3   4   >