Re: DMD won't compile re-init of variable

On Thursday, 30 January 2020 at 21:36:53 UTC, Adam D. Ruppe wrote: On Thursday, 30 January 2020 at 21:09:41 UTC, Simon wrote: How do I revert my variable to the init state? null is the initial state for those. More generally, .init can be used as to get the initial state for any type.

Re: CTFE Status 2

On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd

Re: RFC: patch statement

On Monday, 3 April 2017 at 11:16:57 UTC, Dejan Lekic wrote: I know people her do not like to see proposals that change (add stuff to) the language. However, I strongly feel that for the testing purposes D should provide means to patch any object (no matter whether it is final or not!).

Re: If you needed any more evidence that memory safety is the future...

On Sunday, 5 March 2017 at 11:48:23 UTC, Jacob Carlborg wrote: On 2017-03-03 16:23, Moritz Maxeiner wrote: That would be a good next step from an engineering standpoint, I agree, to proceed to minimize the amount of trust in people you need to have vs verifiable safety. I have considered

Re: foreach for string[string]AA

On Tuesday, 28 February 2017 at 18:16:45 UTC, Anton Pastukhov wrote: On Tuesday, 28 February 2017 at 17:16:43 UTC, Daniel Kozák wrote: V Tue, 28 Feb 2017 15:15:00 + Anton Pastukhov via Digitalmars-d-learn napsáno: I can't see the logic in AA foreach

Re: Getting nice print of struct for debugging

On Saturday, 25 February 2017 at 01:27:09 UTC, Minty Fresh wrote: On Wednesday, 22 February 2017 at 11:18:15 UTC, Martin Tschierschke wrote: [...] Since structs are Plain-old Data and don't do inheritance, the best option is a template mixin. ie. template mixin PrettyPrint {

Re: Getting nice print of struct for debugging

On Wednesday, 22 February 2017 at 11:18:15 UTC, Martin Tschierschke wrote: On Tuesday, 21 February 2017 at 14:02:54 UTC, Jacob Carlborg wrote: [...] Yes, this works, I would say this is the simplest: MyStruct s; foreach (index, name ; FieldNameTuple!MyStruct) writefln("%s: %s", name,

Allocators and Containers

A lot of the usefulness of the std.experimental.allocators module is lost because no other part of the stdlib actually ties into the functionality provided by it. For example, the Array type defined in std.container relies on malloc() directly, so if you wanted to use a type to replace

Re: Convert struct to set of fields and pass it's to constructor

On Wednesday, 1 February 2017 at 13:37:27 UTC, Suliman wrote: Class constructor accept only set if fields like this(string login, string pass) Can I create structure, fill it, and than pass to constructor? Like this: ``` import std.stdio; struct ConnectSettings { string login;

Re: Dlang dynamic compilation

On Monday, 21 November 2016 at 18:59:17 UTC, Ivan Butygin wrote: Hacked ldc sources are here: https://github.com/Hardcode84/ldc/tree/runtime_compile Very cool. Although @runtimeCompile does peeve me, as it seems unnecessarily verbose (being longer than any other attribute, I think). I'd

Re: Overloading relational operators separately; thoughts?

On Saturday, 1 October 2016 at 17:53:44 UTC, Russel Winder wrote: On Sat, 2016-10-01 at 14:55 +, Chris Wright via Digitalmars-d wrote: Groovy doesn't allow you to overload comparison operators individually, and probably most JVM languages likewise. This is to retain compatibility with

Re: Overloading relational operators separately; thoughts?

On Friday, 30 September 2016 at 23:31:19 UTC, Sai wrote: Genuine question: In the post Java languages, how many languages allowed unrestricted operator overloading and did that cause any similar mess? Thanks in advance for any answers. Although there maybe a bit of bias here, but I'd say

Re: Overloading relational operators separately; thoughts?

On Friday, 30 September 2016 at 22:38:07 UTC, Walter Bright wrote: On 9/30/2016 1:14 PM, Minty Fresh wrote: Metathesiophobia Repeatedly suggesting people who don't agree with you have mental disorders does not advance your case and is not appreciated here. Metathesiophobia is not a mental

Re: Overloading relational operators separately; thoughts?

On Friday, 30 September 2016 at 19:46:35 UTC, bachmeier wrote: Claiming that operator overloading only applies to a specific user-defined type makes it worse. Having it work one way for three types, a different way for four other types, and a third way for yet another type doesn't sound like a

Re: Overloading relational operators separately; thoughts?

On Friday, 30 September 2016 at 00:50:54 UTC, Jonathan M Davis wrote: Except that it kind of is. It's an example of a language allowing you to mess with too much and make it so that it doesn't function as expected, which is what happens when you overload operators to act in a way

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 22:27:50 UTC, bachmeier wrote: You're looking for https://www.perl.org/ That's a highly viable language, where you can do things like bury $[ = 1 somewhere in your code to change from 0-indexing to 1-indexing of arrays. They take pride in unpredictable,

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 19:39:35 UTC, Jonathan M Davis wrote: The language can't stop you from doing at least some arbitrary stuff with them (like making + do subtraction), but the whole goal was for user-defined types to be able to act like the built-in types, and as such, it would

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 19:11:55 UTC, pineapple wrote: Relinquish the notion that you or anyone can have the slightest idea what any language feature is "supposed to mean and be used for". Basically what led to D's CTFE implementation in the first place, IIRC.

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 18:07:37 UTC, Russel Winder wrote: On Thu, 2016-09-29 at 10:52 -0700, Walter Bright via Digitalmars-d wrote: On 9/29/2016 9:41 AM, Sai wrote: > > If I understand the issue correctly, one will not be able to > overload <=, >, etc > for symbolic math, like CAS

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 12:54:54 UTC, Jacob Carlborg wrote: BTW, there's a CTFE parser generator for D around somewhere. And that will handle all that the DMD parser does? I don't think so. I agree with this entirely. Lest you have an entire D compiler implemented in CTFE

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 11:29:55 UTC, Russel Winder wrote: However, this has come up many times, and every time Walter says "no, it's wrong". Whilst the C++ iostreams << may have problems, using this as a single point argument as to why overloading fails in all other cases except

Re: Overloading relational operators separately; thoughts?

On Thursday, 29 September 2016 at 04:15:32 UTC, Walter Bright wrote: On 9/28/2016 1:40 PM, Timon Gehr wrote: What's wrong with that usage? Because then something other than comparison is happening with <=, <, >, >= and there'll be nothing in the code to give the user a hint. There's also

Re: Module names shadowing defined functions/templates.

On Thursday, 29 September 2016 at 02:26:15 UTC, Joakim wrote: I ran into this too, it is annoying. I think you're supposed to use different names. It's a rather painful limitation if that were the case. Going with the example I gave, what would an alternative name for the module be? All it's

Re: Module names shadowing defined functions/templates.

As an addendum to the above, the error message I posted was from the overload that takes a delegate as a runtime parameter. Trying to pass template arguments just gives you: Error: template instance leastsq!((p) => p) leastsq is not a template declaration, it is a import

Module names shadowing defined functions/templates.

I ran into this issue just recently when trying to write a least-squares optimization function. Notably, module leastsq; T[] leastsq(alias func, T)(T[] vec, . . .) { . . . } It becomes impossible to import and call this template function from outside the module it's declared

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 20:40:49 UTC, Timon Gehr wrote: This is not surprising. C++ has no good options. This is further made worse by some C++'s more inane design decisions (ie. allowing overloading of the comma operator).

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 20:16:08 UTC, Walter Bright wrote: To reiterate, operator overloading exists in D to support the inclusion of arithmetic library types. Any other purpose is discouraged, and that includes expression templates and things like << for iostreams. It seeds

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 04:02:59 UTC, Walter Bright wrote: The use of them to create DSLs (a technique called "expression templates" in C++) is discouraged in D, for several reasons. The recommended way to create DSLs in D is to parse strings using CTFE. I don't really come from a

Re: Overloading relational operators separately; thoughts?

On Wednesday, 28 September 2016 at 03:12:05 UTC, Jonathan M Davis wrote: On Wednesday, September 28, 2016 01:18:58 Minty Fresh via Digitalmars-d wrote: Basically, having them be overloaded separately is error-prone, and it leads to folks overloading them in ways that have nothing to do

Overloading relational operators separately; thoughts?

Currently, D offers fine grained overloading for most of the unary and arithmetic binary operators, but at some point a decision was made to lump together all of the relational operators (and if necessary, the equality operators) into a single function `opCmp`. And while it does add a lot of