Re: Copy Constructor DIP

On Fri, 13 Jul 2018 at 07:35, Andrei Alexandrescu via Digitalmars-d wrote: > > On 7/12/18 11:45 PM, Manu wrote: > > > > I can see myself getting behind 2 possibilities, no @implicit, or > > @implicit done right. > > A couple of simple ideas are making the process productive. One is to > rely on

Re: Copy Constructor DIP

On Fri, 13 Jul 2018 at 10:35, Atila Neves via Digitalmars-d wrote: > > [...] > > Now that I understand the implicit call `@implicit` makes sense > to me but I'm convinced it'll confuse more people than not. I'll > see if I can come up with a better name. You don't find 'implicit' satisfactory as

Re: Copy Constructor DIP

On Fri, 13 Jul 2018 at 07:40, Andrei Alexandrescu via Digitalmars-d wrote: > > On 7/12/18 11:01 PM, Manu wrote: > > What existing code are you changing the semantics of? > > It's still not clear to me how accepting `this(ref T)` as a magic > > signature that is a copy constructor can break

Re: Copy Constructor DIP

On Fri, 13 Jul 2018 at 04:05, RazvanN via Digitalmars-d wrote: > > > [...] > > The problem with this approach is that some copy constructors > will also be used as assignment operators while others will not, > but with good error messages it could be handled (error on line > `f = d` : opAssign

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 20:15, Meta via Digitalmars-d wrote: > > On Friday, 13 July 2018 at 02:32:59 UTC, Manu wrote: > > Seriously, if I was making this proposal to you, and you were > > in my > > position... there is no way in hell that you'd allow any of us > > to slip > > something so

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 19:15, Andrei Alexandrescu via Digitalmars-d wrote: > > On 7/12/18 6:34 PM, Manu wrote: > > On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d > > wrote: > >> > >> On 07/11/2018 11:11 AM, Atila Neves wrote: > >>> On Wednesday, 11 July 2018 at 07:40:32 UTC,

Re: Copy Constructor DIP

On Thu., 12 Jul. 2018, 7:10 pm Andrei Alexandrescu via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 7/12/18 7:15 PM, Manu wrote: > > On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d > > wrote: > >> > >> On 07/12/2018 11:14 AM, Luís Marques wrote: > >>> On

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 18:25, Andrei Alexandrescu via Digitalmars-d wrote: > > On 7/12/18 4:29 PM, Manu wrote: > > Being able to implement them both independently is*occasionally* > > useful, but 95% of the time, destruct + copy-construct is an equally > > efficient implementation for assignment.

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 08:36, Andrei Alexandrescu via Digitalmars-d wrote: > > On 07/12/2018 11:14 AM, Luís Marques wrote: > > On Thursday, 12 July 2018 at 14:56:33 UTC, Luís Marques wrote: > >> When designing D libraries than lean towards DSL style, I've > >> frequently felt impaired by the lack

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 08:30, Luís Marques via Digitalmars-d wrote: > > On Thursday, 12 July 2018 at 15:14:19 UTC, Luís Marques wrote: > > More details. The DIP says: > > > > "The structName type needs to be identical to typeof(this); an > > error is issued otherwise. This requirement may be

Re: Copy Constructor DIP

On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d wrote: > > Hi everyone! > > I managed to put together a first draft of the DIP for adding the > copy constructor to the language [1]. If anyone is interested, > please take a look. Suggestions and comments about technical > aspects and

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d wrote: > > On 07/11/2018 11:11 AM, Atila Neves wrote: > > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote: > >>> But there's a super explicit `@implicit` thing written right there... > >>> so should we expect that an

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 07:15, Andrei Alexandrescu via Digitalmars-d wrote: > > On 07/12/2018 09:49 AM, Atila Neves wrote: > > On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote: > > > >> [...] > > > >> If by "come in pairs" you mean that you can define them both, then yes, > >> that is the

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 06:50, Andrei Alexandrescu via Digitalmars-d wrote: > > On 07/11/2018 11:11 AM, Atila Neves wrote: > > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote: > >>> But there's a super explicit `@implicit` thing written right there... > >>> so should we expect that an

Re: Copy Constructor DIP

On Thu, 12 Jul 2018 at 06:45, Andrei Alexandrescu via Digitalmars-d wrote: > > On 07/10/2018 06:50 PM, Manu wrote: > > On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d > > wrote: > >> > >> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digital

Re: Copy Constructor DIP

On Wed, 11 Jul 2018 at 23:55, RazvanN via Digitalmars-d wrote: > > > What's wrong with: > > struct S { > > this(ref S copyFrom); > > } > > > > That looks like a perfectly good copy constructor declaration > > ;) I'm just saying, the DIP needs to explain this. > > That is actually a valid

Re: Copy Constructor DIP

On Wed, 11 Jul 2018 at 09:20, vit via Digitalmars-d wrote: > > On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote: > >> But there's a super explicit `@implicit` thing written right > >> there... so should we expect that an *explicit* call to the > >> copy constructor is not allowed? Or

Re: Copy Constructor DIP

On Wed, 11 Jul 2018 at 00:45, RazvanN via Digitalmars-d wrote: > > > But there's a super explicit `@implicit` thing written right > > there... so should we expect that an *explicit* call to the > > copy constructor is not allowed? Or maybe it is allowed and > > `@implicit` is a lie? > > The

Re: Copy Constructor DIP

On Wed, 11 Jul 2018 at 00:40, RazvanN via Digitalmars-d wrote: > > On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote: > > On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d > > wrote: > >> > >> Hi everyone! > >> > >> I managed to put together a first draft of the DIP for adding > >> the

Re: Copy Constructor DIP

On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d wrote: > > On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote: > > 2. It looks like copy constructors are used to perform assignments > > (and not constructions)... but, there is also opAssign. What

Re: Copy Constructor DIP

On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d wrote: > > Hi everyone! > > I managed to put together a first draft of the DIP for adding the > copy constructor to the language [1]. If anyone is interested, > please take a look. Suggestions and comments about technical > aspects and

Re: Sign the installers

On Wed, 27 Jun 2018 at 17:24, Manu wrote: > > On Wed, 27 Jun 2018 at 17:16, Jonathan M Davis via Digitalmars-d > wrote: > > > > On Wednesday, June 27, 2018 16:54:55 Manu via Digitalmars-d wrote: > > > Hey people, > > > > > > So I had a few people

Re: Sign the installers

On Wed, 27 Jun 2018 at 17:16, Jonathan M Davis via Digitalmars-d wrote: > > On Wednesday, June 27, 2018 16:54:55 Manu via Digitalmars-d wrote: > > Hey people, > > > > So I had a few people in the office refuse to install DMD because when > > they launched th

Sign the installers

Hey people, So I had a few people in the office refuse to install DMD because when they launched the installer, Windows displayed the prompt that it was untrusted (ie, unsigned) and not offer the install button without manual override. True also for VisualD. Can we get a key and start signing

Re: Disappointing performance from DMD/Phobos

On Tue., 26 Jun. 2018, 11:45 am Iain Buclaw via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 26 June 2018 at 20:07, Manu via Digitalmars-d > wrote: > > On Tue, 26 Jun 2018 at 10:43, Iain Buclaw via Digitalmars-d > > wrote: > >> > >> On 26

Re: Disappointing performance from DMD/Phobos

On Tue, 26 Jun 2018 at 10:43, Iain Buclaw via Digitalmars-d wrote: > > On 26 June 2018 at 19:41, Manu via Digitalmars-d > wrote: > > On Mon, 25 Jun 2018 at 20:50, Nicholas Wilson via Digitalmars-d > > wrote: > >> > >> Then use LDC! ;) > >

Re: Disappointing performance from DMD/Phobos

On Mon, 25 Jun 2018 at 20:50, Nicholas Wilson via Digitalmars-d wrote: > > Then use LDC! ;) Keep LDC up to date with DMD master daily! ;)

Re: Disappointing performance from DMD/Phobos

On Mon, 25 Jun 2018 at 20:17, Jonathan M Davis via Digitalmars-d wrote: > > dmd's inliner is notoriously poor, I know, but it's still the reference compiler, and it should at least to a reasonable job at the kind of D code that it's *recommended* that users write. That line of code is the sort

Re: Disappointing performance from DMD/Phobos

On Mon, 25 Jun 2018 at 19:10, Manu wrote: > > Some code: > - > struct Entity > { > enum NumSystems = 4; > struct SystemData > { > uint start, length; > } > SystemData[NumSystems] systemData; > @property uint systemBits() const { return

Disappointing performance from DMD/Phobos

Some code: - struct Entity { enum NumSystems = 4; struct SystemData { uint start, length; } SystemData[NumSystems] systemData; @property uint systemBits() const { return systemData[].map!(e => e.length).sum; } } Entity e; e.systemBits(); // <- call

Re: Visual D 0.47.0 released

On Sun, 24 Jun 2018 at 06:10, Rainer Schuetze via Digitalmars-d-announce wrote: > > Hi, > > a new release of Visual D has just been uploaded. Major changes are > > * improved Visual C++ project integration: better dependencies, >automatic libraries, name demangling > * new project wizard > *

Re: Beta 2.081.0

On Sat, 16 Jun 2018 at 21:45, Martin Nowak via Digitalmars-d-announce wrote: > > Glad to announce the first beta for the 2.081.0 release, ♥ to the 52 > contributors for this release. > > http://dlang.org/download.html#dmd_beta > http://dlang.org/changelog/2.081.0.html > > As usual please report

Re: std.digest can't CTFE?

On Fri, 8 Jun 2018 at 11:35, Johannes Pfau via Digitalmars-d wrote: > > Am Sat, 02 Jun 2018 06:31:37 + schrieb Atila Neves: > > > On Friday, 1 June 2018 at 20:12:23 UTC, Kagamin wrote: > >> On Friday, 1 June 2018 at 10:04:52 UTC, Johannes Pfau wrote: > >>> However you want to call it, the

Help with semaphoreci issue?

I have 2 DMD PR's that show this issue with semaphoreci: https://semaphoreci.com/dlang/dmd-2/branches/pull-request-8336/builds/1 I don't understand what's wrong, and whether or not it's my fault... If it's not, I guess someone needs to know about it?

Re: std.digest can't CTFE?

On 31 May 2018 at 18:14, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > On 05/31/2018 06:40 PM, Jonathan M Davis wrote: >> >> On Thursday, May 31, 2018 14:29:13 Manu via Digitalmars-d wrote: >>> >>> "CTFE >>> Digests do not work in CTFE"

Re: std.digest can't CTFE?

at 15:40, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, May 31, 2018 14:29:13 Manu via Digitalmars-d wrote: >> "CTFE >> Digests do not work in CTFE" >> >> >> That's an unfortunate limitation... why is, those things? :( > > If I had to

std.digest can't CTFE?

"CTFE Digests do not work in CTFE" That's an unfortunate limitation... why is, those things? :(

Bad codegen, crashing (win64)

Can anyone that knows how help me with this: https://issues.dlang.org/show_bug.cgi?id=18928 This is a really bad look for my recent evaluation here :/ If a prompt fix is possible, it might not put a bullet in my evaluation, but this rattles peoples confidence.

Re: extern(C++) template problem

On 25 May 2018 at 11:28, Walter Bright via Digitalmars-d wrote: > On 5/23/2018 10:48 AM, Manu wrote: >> >> Sadly, neither of these are correct. >> The type is a class (has vtable, etc), so it is declared in D as a >> class... It is also a class in C++, so it must

Re: T opImplCast(T)() so we can add @disable to it?

On 23 May 2018 at 17:30, Sjoerd Nijboer via Digitalmars-d wrote: > While tinkering with some code I eventually found that the following didn't > do as I expected > > import std.conv; > import std.stdio; > > void main() > { > Foo foo = 5; > writeln(foo); > } >

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 16:34, Rubn via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 22:47:21 UTC, sarn wrote: >> >> On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: >>> >>> I would consider the current state with classes a bug. >>> So ticket

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 15:47, sarn via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: >> >> I would consider the current state with classes a bug. >> So ticket please, it should not require a DIP to change (although Walter >> may

Re: CI buildbots

On 23 May 2018 at 07:09, Seb via Digitalmars-d wrote: > On Monday, 21 May 2018 at 04:46:15 UTC, Manu wrote: >> >> This CI situation with the DMD/druntime repos is not okay. >> It takes ages... **hours** sometimes, for CI to complete. >> It's all this 'auto-tester'

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 10:59, Steven Schveighoffer via Digitalmars-d wrote: > On 5/23/18 1:41 PM, Manu wrote: >> >> On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/22/18 10:15 PM, Manu wrote:

Re: Help with DMD internals

On 23 May 2018 at 06:36, Steven Schveighoffer via Digitalmars-d wrote: > On 5/22/18 9:48 PM, Manu wrote: >> >> On 22 May 2018 at 06:44, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/22/18 1:01 AM, Manu wrote: Ah!

Re: Help with DMD internals

On 20 May 2018 at 13:25, Walter Bright via Digitalmars-d wrote: > On 5/20/2018 12:28 PM, Manu wrote: >> >> I've started digging at some surfac-ey extern(C++) issues. > > > I've improved the definition of how construction works, such as when the > .init happens, in the

Re: extern(C++) template problem

On 23 May 2018 at 03:14, Nicholas Wilson via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 07:09:40 UTC, Manu wrote: >> >> C++: >> --- >> class C {}; >> >> template >> void create(T** x); >>

Re: D's Destructors are What Scott Meyers Warned Us About

On 23 May 2018 at 05:38, Steven Schveighoffer via Digitalmars-d wrote: > On 5/22/18 10:15 PM, Manu wrote: >> >> If you're in the mood to prepare a DIP, I think you should prepare this >> dip: >> >> Support the syntax: >>classInstance.~this(); > > > Isn't this just

Re: Support alias this in module scope?

On 23 May 2018 at 10:12, 12345swordy via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 16:28:22 UTC, H. S. Teoh wrote: >> >> On Wed, May 23, 2018 at 02:34:07PM +, 12345swordy via Digitalmars-d >> wrote: [...] >>> >>> Can you please support actual web forms

extern(C++) template problem

C++: --- class C {}; template void create(T** x); --- D: --- extern(C++) class C {} void create(T)(T* x); --- Trouble is; in CPP, the template

Re: Support alias this in module scope?

On 22 May 2018 at 22:06, VectorThis via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 04:38:48 UTC, Manu wrote: >> >> >> Sure he does! It's a fair call. > > > Hey, it could be worse, you could have wrote this below instead.. > (then imagine the chaos that would

Re: Support alias this in module scope?

On 22 May 2018 at 21:31, rikki cattermole via Digitalmars-d wrote: > On 23/05/2018 4:29 PM, 12345swordy wrote: >> >> On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: >>> >>> >>> extern(C++, FuckOff) >>> { >>> void bah(); >>> void humbug(); >>> } >>> alias

Re: Support alias this in module scope?

On 22 May 2018 at 20:53, Stefan Koch via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 03:44:36 UTC, Manu wrote: >> >> Okay, I'm still really angry about the stupid stupid decision to make C++ >> namespaces into scopes rather than just a detail used for

Re: D's Destructors are What Scott Meyers Warned Us About

On 22 May 2018 at 19:39, 12345swordy via Digitalmars-d wrote: > On Wednesday, 23 May 2018 at 02:15:25 UTC, Manu wrote: >> >> It should recurse the ClassInfo calling the dtors there to perform a >> full virtual destruction. > > > Why? That seems restrictive as there is

Support alias this in module scope?

Okay, I'm still really angry about the stupid stupid decision to make C++ namespaces into scopes rather than just a detail used for mangling, with absolutely no consultation of the community, in particular the target audience, who are unanimously annoyed as far as I can tell... I'm unsatisfied by

Re: D's Destructors are What Scott Meyers Warned Us About

On 22 May 2018 at 18:59, sarn via Digitalmars-d wrote: > (I'm referring to Scott's 2014 DConf talk: > https://www.youtube.com/watch?v=KAWA1DuvCnQ) > > I was actually preparing a DIP about this when Manu posted to the forums > about his own related problems with C++

Re: Help with DMD internals

On 22 May 2018 at 06:44, Steven Schveighoffer via Digitalmars-d wrote: > On 5/22/18 1:01 AM, Manu wrote: >> >> On 21 May 2018 at 15:51, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/21/18 6:37 PM, Manu wrote:

Re: DConf 2018 Videos

On 21 May 2018 at 17:16, Mike Parker via Digitalmars-d wrote: > On Monday, 21 May 2018 at 22:09:08 UTC, SrMordred wrote: >> >> There is some place where I can find this year conference videos with or >> without slides? >> Thanks! > > > Day 1: >

Re: Help with DMD internals

On 21 May 2018 at 15:51, Steven Schveighoffer via Digitalmars-d wrote: > On 5/21/18 6:37 PM, Manu wrote: >> >> On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> Uninitialized, but allocated and usable. The

Re: extern(C++) classes; dtor must go in vtable

On 21 May 2018 at 15:39, Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On 5/21/18 6:26 PM, Manu wrote: >> >> On 21 May 2018 at 14:53, Jonathan M Davis via Digitalmars-d >> <digitalmars-d@puremagic.com> wrote: >>> >

Re: Help with DMD internals

On 21 May 2018 at 15:29, Steven Schveighoffer via Digitalmars-d wrote: > On 5/21/18 6:18 PM, Manu wrote: >> >> On 21 May 2018 at 06:10, Steven Schveighoffer via Digitalmars-d >> wrote: >>> >>> On 5/20/18 9:49 PM, Manu wrote:

Re: extern(C++) classes; dtor must go in vtable

On 21 May 2018 at 15:03, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Monday, May 21, 2018 14:33:44 Manu via Digitalmars-d wrote: >> extern(C++) classes. >> >> Currently, we don't add destructors to the vtable... we suggest that >>

Re: extern(C++) classes; dtor must go in vtable

On 21 May 2018 at 14:53, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Monday, May 21, 2018 14:33:44 Manu via Digitalmars-d wrote: >> How do virtual destructors work in normal D classes? > > It is my understanding that destructors in D are nev

Re: CI buildbots

On 21 May 2018 at 09:22, Jonathan Marler via Digitalmars-d wrote: > On Monday, 21 May 2018 at 04:46:15 UTC, Manu wrote: >> >> This CI situation with the DMD/druntime repos is not okay. >> It takes ages... **hours** sometimes, for CI to complete. >> It's all this

Re: Help with DMD internals

On 21 May 2018 at 06:10, Steven Schveighoffer via Digitalmars-d wrote: > On 5/20/18 9:49 PM, Manu wrote: >> >> On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d >> wrote: >>> >>> On 5/20/2018 12:28 PM, Manu wrote:

extern(C++) classes; dtor must go in vtable

extern(C++) classes. Currently, we don't add destructors to the vtable... we suggest that users need to create some dummy virtual functions to fill those vtable slots so that the vtable layout otherwise matches the C++ class. This leaves us in a position where destruction doesn't work for

Re: CI buildbots

On 20 May 2018 at 21:46, Manu wrote: > This CI situation with the DMD/druntime repos is not okay. > It takes ages... **hours** sometimes, for CI to complete. > It's all this 'auto-tester' one, which seems to lock up on the last few tests. > > This makes DMD is a rather

CI buildbots

This CI situation with the DMD/druntime repos is not okay. It takes ages... **hours** sometimes, for CI to complete. It's all this 'auto-tester' one, which seems to lock up on the last few tests. This makes DMD is a rather unenjoyable project to contribute to. I had a sudden burst of inspiration,

Re: A pattern I'd like to see more of - Parsing template parameter tuples

I don't really like that SomeObject() will be instantiated a crap load of times for every possible combination and order of options that a user might want to supply. How do you control the bloat in a way that people won't mess up frequently? On 20 May 2018 at 17:58, Neia Neutuladh via

Re: Help with DMD internals

On 20 May 2018 at 17:14, Walter Bright via Digitalmars-d wrote: > On 5/20/2018 12:28 PM, Manu wrote: >> >>Is re-initialisation to 'init' part of destruction, > > > No. > >> or is it a >> separate post-process? (I feel it's a post-process) > > > Yes, and only for

Re: Help with DMD internals

On 20 May 2018 at 12:28, Manu wrote: > > [...] Then... next up, extern(C++) classes need to place __xdtor in the vtable (posix uses 2 slots). We need the vtable to match naturally, without advising people to add a dummy method. I also have a hack in progress to support

Help with DMD internals

I've started digging at some surfac-ey extern(C++) issues. First up, I desperately want a document that describes D's precise construction/destruction rules; there are a bunch of generated functions, they get called, in what order, and under what conditions? Construction: What is the order of

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17 May 2018 at 13:25, Shachar Shemesh via Digitalmars-d wrote: > On 17/05/18 22:29, Manu wrote: >> >> >> This is great! >> I've wanted this on numerous occasions when interacting with C++ code. >> This will make interaction more complete. >> >> Within

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17 May 2018 at 01:12, Mike Parker via Digitalmars-d wrote: > This is the review thread for the first Community Review round for DIP 1014, > "Hooking D's struct move semantics". > > All review-related feedback on and discussion of the DIP should occur in > this

Re: in/out contracts on prototypes

On Wed., 16 May 2018, 12:52 pm Jonathan M Davis via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On Wednesday, May 16, 2018 12:16:11 Manu via Digitalmars-d wrote: > > So, in/out contracts are cool. They can be used to assert valid value > > ranges for argume

in/out contracts on prototypes

So, in/out contracts are cool. They can be used to assert valid value ranges for arguments and return values. This is useful for proving correctness, and also, this limiting of value ranges is information that the optimiser can take and use in various optimisations. I often call to extern C/C++

Re: On emulating C++ Namespaces (don't ask why)

On 4 May 2018 at 10:50, 0x via Digitalmars-d wrote: > What am I violating here apart from the truth that our Mr. Walter doesn't > like namespaces: > > interface tlvs > { > enum tlv { addr }; > >static: > void header(); > } > > Is this cool? > >

Re: Release D 2.080.0

On 1 May 2018 at 17:00, Martin Nowak via Digitalmars-d-announce wrote: > Glad to announce D 2.080.0. > > This release comes with CTFE support for log, exp and a couple of more > math functions. There is also a new isReturnOnStack trait, an apply > function

Re: Who says we can't call C++ constructors?

On 21 April 2018 at 05:41, Atila Neves via Digitalmars-d-announce wrote: > From https://dlang.org/spec/cpp_interface.html: > > "C++ constructors, copy constructors, move constructors and destructors > cannot be called directly in D code". > > O RLY? > >

Re: Small Buffer Optimization for string and friends

On 19 April 2018 at 02:22, Walter Bright via Digitalmars-d wrote: > On 4/8/2012 7:26 AM, Manu wrote: >> >> Is it realistic that anyone can actually use raw d-string's in an app that >> performs a lot of string manipulation? I bet most people end up with a >> custom

Re: Small Buffer Optimization for string and friends

On Wed., 18 Apr. 2018, 8:36 pm Manu, wrote: > On Wed., 18 Apr. 2018, 1:00 pm Walter Bright via Digitalmars-d, < > digitalmars-d@puremagic.com> wrote: > >> On 4/8/2012 7:29 AM, Andrei Alexandrescu wrote: >> > On 4/8/12 1:33 AM, Daniel Murphy wrote: >> >> - Would generate

Re: Small Buffer Optimization for string and friends

On Wed., 18 Apr. 2018, 1:00 pm Walter Bright via Digitalmars-d, < digitalmars-d@puremagic.com> wrote: > On 4/8/2012 7:29 AM, Andrei Alexandrescu wrote: > > On 4/8/12 1:33 AM, Daniel Murphy wrote: > >> - Would generate false pointers > > Fair point but we're also moving to precise collection :o).

Re: CTFE in .di files

On 18 April 2018 at 08:10, Stefan Koch via Digitalmars-d wrote: > On Tuesday, 17 April 2018 at 22:19:19 UTC, Manu wrote: >> >> I've been having some problems like this: >> https://issues.dlang.org/show_bug.cgi?id=18774 >> >> I have .di files with mixins that generate

CTFE in .di files

I've been having some problems like this: https://issues.dlang.org/show_bug.cgi?id=18774 I have .di files with mixins that generate declarations using CTFE. Trouble is, executing the CTFE seems to leave residual references to symbols which result in unresolved link errors in the client of the .di

Re: Invading^W The Sydney C++ Meetup

On 2 April 2018 at 00:46, Nicholas Wilson via Digitalmars-d wrote: > On Monday, 2 April 2018 at 07:15:22 UTC, sarn wrote: >> >> This feels like a long shot, but I figure it's worth a try. >> >> I'll be at the Sydney C++ Meetup this Thursday (and other Thursdays, no >>

Re: rvalues -> ref (yup... again!)

On 1 April 2018 at 11:55, Timon Gehr via Digitalmars-d wrote: > On 01.04.2018 19:20, Andrei Alexandrescu wrote: >> >> On 3/28/18 7:50 AM, Timon Gehr wrote: >>> >>> "The proposal could be amended to accept mutable ref's depending on the >>> value-judgement balancing

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 18:52, Walter Bright via Digitalmars-d wrote: > On 3/30/2018 6:03 PM, Manu wrote: >> >> Sadly, I don't think I'll be able to make it to DConf this year... > > > :-( > >> which is probably a reason for rejoice of literally everybody >> attending! :P

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 16:09, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Friday, March 30, 2018 14:47:06 Manu via Digitalmars-d wrote: >> On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d >> > I want to be able to look at a fun

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 12:24, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Friday, March 30, 2018 11:01:23 Manu via Digitalmars-d wrote: >> On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d >> >> <digitalmars-d@puremagic.com&g

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 02:47, Kagamin via Digitalmars-d wrote: > > The only criticism against rvalue references I saw was when the > reference outlives the temporary. That's the only *technical* criticism I've ever heard too. Fortunately, D now has mechanisms for

Re: rvalues -> ref (yup... again!)

On 30 March 2018 at 02:06, Atila Neves via Digitalmars-d wrote: > On Tuesday, 27 March 2018 at 18:14:18 UTC, Manu wrote: >> >> On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d >> wrote: >>> >>> On Monday, 26 March 2018 at 19:24:13

Re: rvalues -> ref (yup... again!)

On 29 March 2018 at 21:08, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, March 29, 2018 23:28:54 Nick Sabalausky via Digitalmars-d > wrote: >> On 03/23/2018 09:06 PM, Jonathan M Davis wrote: >> > My biggest concern in all of this is that I don't want to

Re: rvalues -> ref (yup... again!)

On 28 March 2018 at 05:38, Timon Gehr via Digitalmars-d wrote: > On 27.03.2018 22:25, Rubn wrote: >> >> >> D already has move semantics, an easy solution to this is to just use >> another keyword. It doesn't have to bind to const ref to get what is >> desired: >> >>

Re: rvalues -> ref (yup... again!)

On 28 March 2018 at 05:22, Timon Gehr via Digitalmars-d wrote: > On 27.03.2018 20:14, Manu wrote: >> >> That's exactly what I've been saying. For like, 9 years.. >> It looks like this: >> >> https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx-rval_to_ref.md

Re: rvalues -> ref (yup... again!)

On 28 Mar. 2018 4:35 am, "Timon Gehr via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On 27.03.2018 20:14, Manu wrote: > That's exactly what I've been saying. For like, 9 years.. > It looks like this: > https://github.com/TurkeyMan/DIPs/blob/ref_args/DIPs/DIP1xxx > -rval_to_ref.md >

Re: rvalues -> ref (yup... again!)

On 27 March 2018 at 00:14, Atila Neves via Digitalmars-d wrote: > On Monday, 26 March 2018 at 19:24:13 UTC, Manu wrote: >> >> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d >> wrote: >>> >>> On Friday, 23 March 2018 at 22:01:44

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 17:30, Rubn via Digitalmars-d wrote: > On Monday, 26 March 2018 at 14:40:03 UTC, Atila Neves wrote: >> >> C++ T&& (Rvalue reference) -> D T > > > Not really, in C++ it is an actual reference and you get to choose which > function actually does the

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 19:25, Manu wrote: > On 26 March 2018 at 16:21, Rubn via Digitalmars-d > wrote: >> On Monday, 26 March 2018 at 22:48:38 UTC, Walter Bright wrote: >>> >>> On 3/26/2018 12:24 PM, Manu wrote: On 26 March 2018 at 07:40,

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 16:21, Rubn via Digitalmars-d wrote: > On Monday, 26 March 2018 at 22:48:38 UTC, Walter Bright wrote: >> >> On 3/26/2018 12:24 PM, Manu wrote: >>> >>> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d C++ const T& -> D T >>> >>>

Re: rvalues -> ref (yup... again!)

On 26 March 2018 at 15:48, Walter Bright via Digitalmars-d wrote: > On 3/26/2018 12:24 PM, Manu wrote: >> >> On 26 March 2018 at 07:40, Atila Neves via Digitalmars-d >>> >>> C++ const T& -> D T >> >> >> Yeah, no... T may be big. Copying a large thing sucks. Memory

<    1   2   3   4   5   6   7   8   9   10   >