Re: libdvbv5_d

On Saturday, 24 March 2018 at 14:25:19 UTC, Russel Winder wrote: I suspect no-one other than me is interested in libdvbv5, but just in case: libdvbv5_d (https://github.com/russel/libdvbv5_d) is a D binding created using DStep and lot of manual hacking. There is no test suite. :-( Also there is

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Sat, Mar 24, 2018 at 10:30:31PM -0600, Jonathan M Davis via Digitalmars-d wrote: > On Saturday, March 24, 2018 09:59:44 H. S. Teoh via Digitalmars-d wrote: > > And given the defensiveness surrounding std.getopt, my conclusion > > can only be: dump std.getopt, roll my own. It's sad, since in >

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

On Sunday, 25 March 2018 at 01:43:43 UTC, Jonathan M Davis wrote: On Sunday, March 25, 2018 00:34:38 Rubn via Digitalmars-d wrote: On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: > Auto ref allows the unnecessary copy to be avoided for > lvalues and creates a temporary (as part o

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Saturday, March 24, 2018 09:59:44 H. S. Teoh via Digitalmars-d wrote: > And given the defensiveness surrounding std.getopt, my conclusion can > only be: dump std.getopt, roll my own. It's sad, since in general > Phobos design tends to be superior to its C++ counterparts. But we then > have war

Re: alias this constructor

On Sunday, March 25, 2018 06:24:35 Shachar Shemesh via Digitalmars-d wrote: > On 25/03/18 04:51, Jonathan M Davis wrote: > > On Sunday, March 25, 2018 00:47:20 Dave Jones via Digitalmars-d wrote: > >> struct Foo > >> { > >> > >> int x; > >> alias x this; > >> > >> } > >> > >> Foo f = 12

Re: CTFE ^^ (pow)

On 24 March 2018 at 18:10, Walter Bright via Digitalmars-d wrote: > On 3/24/2018 9:37 AM, Manu wrote: >> >> I'm not sure why I seem to have to defend the idea that it's a *great >> thing* that D (in theory; according to the advertising brochure) does >> away with these requirements. > > > It is in

Re: alias this constructor

On 25/03/18 04:51, Jonathan M Davis wrote: On Sunday, March 25, 2018 00:47:20 Dave Jones via Digitalmars-d wrote: struct Foo { int x; alias x this; } Foo f = 12; // error Foo foo; f = 12; // this is OK any reason why the first cant be allowed? Because it was deemed to cause

Re: alias this constructor

On Sunday, 25 March 2018 at 00:47:20 UTC, Dave Jones wrote: struct Foo { int x; alias x this; } Foo f = 12; // error You just need to define a constructor that takes an int. alias this is all about taking an existing object and substituting a member for it - emphasis on *existing* ob

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

On 03/24/2018 03:03 AM, Jonathan M Davis wrote: On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d wrote: Why require the callee's author to add boilerplate? Just do it for all ref params that are given an rvalue. Because if the point of the function accepting its argument

Re: alias this constructor

On Sunday, March 25, 2018 00:47:20 Dave Jones via Digitalmars-d wrote: > struct Foo > { > int x; > alias x this; > } > > Foo f = 12; // error > > Foo foo; > f = 12; // this is OK > > any reason why the first cant be allowed? Because it was deemed to cause too many problems. C++ code

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

On Sunday, March 25, 2018 00:34:38 Rubn via Digitalmars-d wrote: > On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: > > Auto ref allows the unnecessary copy to be avoided for lvalues > > and creates a temporary (as part of passing the value) for > > rvalues. It has downsides (virtual

Re: CTFE ^^ (pow)

On 3/24/2018 9:37 AM, Manu wrote: I'm not sure why I seem to have to defend the idea that it's a *great thing* that D (in theory; according to the advertising brochure) does away with these requirements. It is indeed a great idea. I'm just making the case that it isn't a blocker to not have it

Re: Must ranges support `r1 = r2;`?

On Sunday, March 25, 2018 00:28:32 ag0aep6g via Digitalmars-d wrote: > On 03/25/2018 12:02 AM, Jonathan M Davis wrote: > > auto range2 = range1; // now, range1 can't be used until it's assigned > > to > > range2.popFront(); > > > > range1 = range2; // now, range2 can't be used until it's assigned t

alias this constructor

struct Foo { int x; alias x this; } Foo f = 12; // error Foo foo; f = 12; // this is OK any reason why the first cant be allowed?

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

On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: Here is a small proof of concept I made to demonstrate how easy it seems to be to use `auto ref` to call a C++ virtual const& function without incurring any more copies than would happen with the same calls from C++. I'm sure it cou

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

On Saturday, 24 March 2018 at 23:03:36 UTC, John Colvin wrote: Auto ref allows the unnecessary copy to be avoided for lvalues and creates a temporary (as part of passing the value) for rvalues. It has downsides (virtual functions and extern(C++), but it does directly address the problem you're

Re: CTFE ^^ (pow)

On 03/24/2018 12:37 PM, Manu wrote: I understand table generation, that is the standard approach. It's Huh? Then I guess I don't understand why you implied that the alternative to CTFE was manually regenerating and copy-pasting tables: >> On 3/23/2018 11:09 AM, Manu wrote: >>> Like, in this

Re: CTFE ^^ (pow)

On 03/24/2018 09:53 AM, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d wrote: [...] I can't recall ever seeing anyone else use this technique (other than Nick!), but it works and isn't that bad. It's not all that uncommon. I've worked with projects

Re: Must ranges support `r1 = r2;`?

On 03/25/2018 12:02 AM, Jonathan M Davis wrote: auto range2 = range1; // now, range1 can't be used until it's assigned to range2.popFront(); range1 = range2; // now, range2 can't be used until it's assigned to range1.popFront(); And I don't think that RefRange violates that. What RefRange vio

Re: Must ranges support `r1 = r2;`?

On 03/24/2018 11:36 PM, Simen Kjærås wrote: void main() {     import std.range;     import std.stdio;     string s = "foo";     auto r = refRange(&s);     auto r2 = r;     r2 = r2.save;     /* Surprising: Effectively just does `s = s;` (i.e., nothing). */     r2.popFront();     wr

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

On Saturday, 24 March 2018 at 17:30:35 UTC, Manu wrote: On 24 March 2018 at 04:57, John Colvin via Digitalmars-d wrote: On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d wrote: On 3/23/2018 11:0

Re: Must ranges support `r1 = r2;`?

On Saturday, March 24, 2018 22:44:35 ag0aep6g via Digitalmars-d wrote: > Long version: > ("std.range and std.algorithm can't handle refRange"). > > Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what > other Phobos code expects. >

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

On Saturday, 24 March 2018 at 11:57:25 UTC, John Colvin wrote: I understand what you want, but I'm struggling to understand why it's such a huge deal. The reason you want to pass by reference is for performance, to avoid copying the data at the call boundary. It's pretty simple: float foo()

Re: Must ranges support `r1 = r2;`?

On Saturday, 24 March 2018 at 22:36:55 UTC, Simen Kjærås wrote: struct RefRange(R) { R* innerRange; this(R* innerRange) { this.innerRange = innerRange; } void popFront() { innerRange.popFront(); } @property auto front() { return innerRange.front;

Re: Must ranges support `r1 = r2;`?

On Saturday, 24 March 2018 at 21:44:35 UTC, ag0aep6g wrote: Long version: ("std.range and std.algorithm can't handle refRange"). Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what other Phobos code expects. Question is: Wh

Re: Must ranges support `r1 = r2;`?

On 03/24/2018 10:57 PM, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 10:44:35PM +0100, ag0aep6g via Digitalmars-d wrote: [...] Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what other Phobos code expects. [...] Short answer: if r1=r2 is meant to save the current position in

Re: Must ranges support `r1 = r2;`?

On Sat, Mar 24, 2018 at 10:44:35PM +0100, ag0aep6g via Digitalmars-d wrote: > Long version: > ("std.range and std.algorithm can't handle refRange"). > > Short version: With two `std.range.RefRange`s, `r1 = r2;` does not > what other Phobos code expe

Must ranges support `r1 = r2;`?

Long version: ("std.range and std.algorithm can't handle refRange"). Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what other Phobos code expects. Question is: Who's at fault? Where do I fix this? Do ranges have to support

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Sat, Mar 24, 2018 at 05:24:28PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 3/24/18 12:59 PM, H. S. Teoh wrote: > > On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via > > Digitalmars-d wrote: > > [...] > > > Anyhow. Right now the order of processing is the same as t

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On 3/24/18 12:59 PM, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] Anyhow. Right now the order of processing is the same as the lexical order in which flags are passed to getopt. There may be use cases for which that's the more de

Re: code.dlang.org having problems?

On Sat, Mar 24, 2018 at 04:59:49PM +, Russel Winder via Digitalmars-d wrote: > On Sat, 2018-03-24 at 09:45 -0700, H. S. Teoh via Digitalmars-d wrote: > > […] > > > > That is why a sane build system should always cache dependencies > > locally, and not have to rely on network servers being alwa

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

Here is what I've used if I had to: https://p0nce.github.io/d-idioms/#Rvalue-references:-Understanding-auto-ref-and-then-not-using-it

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Saturday, 24 March 2018 at 16:11:18 UTC, Andrei Alexandrescu wrote: Anyhow. Right now the order of processing is the same as the lexical order in which flags are passed to getopt. There may be use cases for which that's the more desirable way to go about things, so if you author a PR to chan

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

On 24 March 2018 at 07:56, kinke via Digitalmars-d wrote: > On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: >> >> What I'm saying is that I don't really buy Jonathan's argument. Basically, >> you should just pass the correct arguments to functions, as you always need >> to do. If you

Re: code.dlang.org having problems?

On Saturday, 24 March 2018 at 16:14:20 UTC, rikki cattermole wrote: On 25/03/2018 5:10 AM, Russel Winder wrote: On Sun, 2018-03-25 at 04:50 +1300, rikki cattermole via Digitalmars-d wrote: On 25/03/2018 4:48 AM, Russel Winder wrote: It seems Dub is dead, and thus so are new Dub builds. code.d

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

On 24 March 2018 at 06:49, Timon Gehr via Digitalmars-d wrote: > On 24.03.2018 05:03, Manu wrote: >> >> I have no idea what this paragraph means... can you elaborate further >> what you're talking about? > > This works: > > struct S{ > int x; > void inc(){ > this.x++; // note: 'thi

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

On 24 March 2018 at 04:57, John Colvin via Digitalmars-d wrote: > On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: >> >> Forked from the x^^y thread... >> >> On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d >> wrote: >>> >>> On 3/23/2018 11:09 AM, Manu wrote: [...] >

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

Am Sat, 24 Mar 2018 17:10:53 + schrieb Johannes Pfau: > Am Sat, 24 Mar 2018 01:04:00 -0600 schrieb Jonathan M Davis: > >> As it stands, because a function can't accept rvalues by ref, it's >> usually reasonable to assume that a function accepts its argument by >> ref because it's mutating tha

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

Am Sat, 24 Mar 2018 01:04:00 -0600 schrieb Jonathan M Davis: > As it stands, because a function can't accept rvalues by ref, it's > usually reasonable to assume that a function accepts its argument by ref > because it's mutating that argument rather than simply because it's > trying to avoid a cop

Re: code.dlang.org having problems?

On Sat, 2018-03-24 at 16:59 +, Seb via Digitalmars-d wrote: > On Saturday, 24 March 2018 at 15:48:21 UTC, Russel Winder wrote: > > It seems Dub is dead, and thus so are new Dub builds. > > > > code.dlang.org appears to be having a 500 problem. I think the > > website is recovering as I write,

Re: code.dlang.org having problems?

On Sun, Mar 25, 2018 at 05:52:42AM +1300, rikki cattermole via Digitalmars-d wrote: > On 25/03/2018 5:45 AM, H. S. Teoh wrote: > > On Sat, Mar 24, 2018 at 04:11:36PM +, Russel Winder via Digitalmars-d > > wrote: > > > On Sat, 2018-03-24 at 09:01 -0700, H. S. Teoh via Digitalmars-d wrote: > >

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Sat, Mar 24, 2018 at 12:11:18PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] > Anyhow. Right now the order of processing is the same as the lexical > order in which flags are passed to getopt. There may be use cases for > which that's the more desirable way to go about things, so i

Re: code.dlang.org having problems?

On Saturday, 24 March 2018 at 15:48:21 UTC, Russel Winder wrote: It seems Dub is dead, and thus so are new Dub builds. code.dlang.org appears to be having a 500 problem. I think the website is recovering as I write, but still no Dub builds so the point remains: no code.dlang.org, no Dub builds

Re: code.dlang.org having problems?

On Sat, 2018-03-24 at 09:45 -0700, H. S. Teoh via Digitalmars-d wrote: > […] > > That is why a sane build system should always cache dependencies > locally, and not have to rely on network servers being always available. Dub does exactly that, so not a problem. Dub even has the --skip-registry op

Re: code.dlang.org having problems?

On 25/03/2018 5:45 AM, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 04:11:36PM +, Russel Winder via Digitalmars-d wrote: On Sat, 2018-03-24 at 09:01 -0700, H. S. Teoh via Digitalmars-d wrote: On Sat, Mar 24, 2018 at 03:48:21PM +, Russel Winder via Digitalmars-d wrote: It seems Dub is dead

Re: CTFE ^^ (pow)

On 2018-03-24 00:37, Nick Sabalausky wrote: OAuth is a phisher's paradise. But that aside, it's never made any sense to me for projects to self-impose a policy of "If you've found a bug, and you're non-registered, we don't want to hear about it." I would think any self-respecting project wo

Re: CTFE ^^ (pow)

On 2018-03-23 20:25, Jonathan M Davis wrote: Really? I've dealt with relatively few projects that use github as a bug tracker, and it's been my experience that most anything that's really serious has its own bugtracker (usually some form of bugzilla) - though most such projects predate github by

Re: code.dlang.org having problems?

On Sat, Mar 24, 2018 at 04:11:36PM +, Russel Winder via Digitalmars-d wrote: > On Sat, 2018-03-24 at 09:01 -0700, H. S. Teoh via Digitalmars-d wrote: > > On Sat, Mar 24, 2018 at 03:48:21PM +, Russel Winder via Digitalmars-d > > wrote: > > > It seems Dub is dead, and thus so are new Dub buil

Re: CTFE ^^ (pow)

On 2018-03-23 13:34, bauss wrote: What do you mean? https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&product=gcc&resolution=--- That's only limited to 500, here's a list of 10 000: https://gcc.gnu.org/bugzilla/buglist.cgi?component=c%2B%2B&limit=0&order=bug_status%2Cpriority%2Cass

Re: CTFE ^^ (pow)

On 24 March 2018 at 01:42, Walter Bright via Digitalmars-d wrote: > On 3/23/2018 11:09 AM, Manu wrote: >> >> Like, in this particular project, being able to generate all tables at >> compile time is the thing that distinguishes the D code from the C++ >> code; it's the *whole point*... If I have t

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

On Saturday, 24 March 2018 at 15:36:14 UTC, Timon Gehr wrote: On 24.03.2018 15:56, kinke wrote: I agree, but restricting it to const ref would be enough for almost all of my use cases. The MS C++ compiler just emits a warning when binding an rvalue to a mutable ref ('nonstandard extension used

Re: code.dlang.org having problems?

On 25/03/2018 5:10 AM, Russel Winder wrote: On Sun, 2018-03-25 at 04:50 +1300, rikki cattermole via Digitalmars-d wrote: On 25/03/2018 4:48 AM, Russel Winder wrote: It seems Dub is dead, and thus so are new Dub builds. code.dlang.org appears to be having a 500 problem. I think the website is r

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On 03/24/2018 09:36 AM, H. S. Teoh wrote: On Sat, Mar 24, 2018 at 08:27:48AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] At a point where a realistic benchmarks shows a need. Without a motivating measurement, making getopt faster would be a waste of time. [...] Guys, for crying

Re: code.dlang.org having problems?

On Sat, 2018-03-24 at 09:01 -0700, H. S. Teoh via Digitalmars-d wrote: > On Sat, Mar 24, 2018 at 03:48:21PM +, Russel Winder via Digitalmars-d > wrote: > > It seems Dub is dead, and thus so are new Dub builds. > > > > code.dlang.org appears to be having a 500 problem. I think the website > > i

Re: code.dlang.org having problems?

On Sun, 2018-03-25 at 04:50 +1300, rikki cattermole via Digitalmars-d wrote: > On 25/03/2018 4:48 AM, Russel Winder wrote: > > It seems Dub is dead, and thus so are new Dub builds. > > > > code.dlang.org appears to be having a 500 problem. I think the website is > > recovering as I write, but stil

Re: code.dlang.org having problems?

On Sat, Mar 24, 2018 at 03:48:21PM +, Russel Winder via Digitalmars-d wrote: > It seems Dub is dead, and thus so are new Dub builds. > > code.dlang.org appears to be having a 500 problem. I think the website > is recovering as I write, but still no Dub builds so the point > remains: no code.dl

Re: code.dlang.org having problems?

On 25/03/2018 4:48 AM, Russel Winder wrote: It seems Dub is dead, and thus so are new Dub builds. code.dlang.org appears to be having a 500 problem. I think the website is recovering as I write, but still no Dub builds so the point remains: no code.dlang.org, no Dub builds. :-( Tip: $ dub --s

code.dlang.org having problems?

It seems Dub is dead, and thus so are new Dub builds. code.dlang.org appears to be having a 500 problem. I think the website is recovering as I write, but still no Dub builds so the point remains: no code.dlang.org, no Dub builds. :-( -- Russel. == Dr Russ

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

On 24.03.2018 15:56, kinke wrote: On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: What I'm saying is that I don't really buy Jonathan's argument. Basically, you should just pass the correct arguments to functions, as you always need to do. If you cannot use the result of some muta

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Sat, Mar 24, 2018 at 01:43:10PM +, Adam D. Ruppe via Digitalmars-d wrote: > On Friday, 23 March 2018 at 23:29:48 UTC, H. S. Teoh wrote: > > I just ran into this seemingly small problem: > > The way I'd do this is to only use getopt to build the lists, then > actually process them externally

Re: About making Phobos @safe

On Friday, 23 March 2018 at 20:33:40 UTC, Jack Stouffer wrote: If @safe doesn't protect against buffer overflows then chuck the whole thing out the window and start over. Then chuck the whole thing out the window and start your own review over and include the @safe code this time. You say it

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

On Saturday, 24 March 2018 at 13:49:13 UTC, Timon Gehr wrote: What I'm saying is that I don't really buy Jonathan's argument. Basically, you should just pass the correct arguments to functions, as you always need to do. If you cannot use the result of some mutation that you need to use, you wil

libdvbv5_d

I suspect no-one other than me is interested in libdvbv5, but just in case: libdvbv5_d (https://github.com/russel/libdvbv5_d) is a D binding created using DStep and lot of manual hacking. There is no test suite. :-( Also there is not yet a Dub package. The driving application at the moment is DVBT

Re: CTFE ^^ (pow)

On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d wrote: [...] > This file: > > https://github.com/dlang/dmd/blob/master/src/dmd/backend/optabgen.c > > computes tables, and writes several tables out to several .c files, > which are then #include'd into the main build. It

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

On 24.03.2018 05:03, Manu wrote: On 23 March 2018 at 20:17, Timon Gehr via Digitalmars-d wrote: On 24.03.2018 02:16, Manu wrote: This is an interesting point, but I don't think it changes the balance in any way. Thinking of the majority of my anecdotal cases, I don't think it would be a probl

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Friday, 23 March 2018 at 23:29:48 UTC, H. S. Teoh wrote: I just ran into this seemingly small problem: The way I'd do this is to only use getopt to build the lists, then actually process them externally. (lol adding another loop) string[] searchPaths; string[] files; getopt(args, "l",

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On Sat, Mar 24, 2018 at 08:27:48AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] > At a point where a realistic benchmarks shows a need. Without a motivating > measurement, making getopt faster would be a waste of time. [...] Guys, for crying out loud, my original complaint was not *p

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

On Saturday, 24 March 2018 at 11:57:25 UTC, John Colvin wrote: I understand what you want, but I'm struggling to understand why it's such a huge deal. ... What I would do in D currently to get the same performance and API: void foo(float[32] v) { foo(v); } void foo(ref float[32] v) { ... } o

Binding rvalues to ref parameters

Hi Manu and everyone else: I'm publicly distributing what started as a private email to Manu - I'm trying to get a point across that is important and of general interest. I've seen in a recent thread (titled "rvalues -> ref (yup... again!)") that Manu brought up the implicit conversion of rv

Re: Am I reading this wrong, or is std.getopt *really* this stupid?

On 03/24/2018 01:55 AM, Chris Katko wrote: On Saturday, 24 March 2018 at 03:04:41 UTC, Andrei Alexandrescu wrote: On 3/23/18 7:29 PM, H. S. Teoh wrote: Well, looking at the implementation of std.getopt turned up the disturbing fact that the program's argument list is actually scanned *multiple

Re: does it scale to have 1 person approve of all phobos additions?

On 03/24/2018 02:29 AM, Meta wrote: I'll go review something. That's the spirit! Thanks!! -- Andrei

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

On Friday, 23 March 2018 at 22:01:44 UTC, Manu wrote: Forked from the x^^y thread... On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d wrote: On 3/23/2018 11:09 AM, Manu wrote: [...] Rvalue references are not trivial and can have major unintended consequences. They're a rather u

Re: About making Phobos @safe

On Friday, 23 March 2018 at 20:33:40 UTC, Jack Stouffer wrote: On Friday, 23 March 2018 at 17:31:09 UTC, Jesse Phillips wrote: [...] If @safe doesn't protect against buffer overflows then chuck the whole thing out the window and start over. [...] zlib sources are included in phobos. It do

Re: CTFE ^^ (pow)

On 3/23/2018 11:09 AM, Manu wrote: Like, in this particular project, being able to generate all tables at compile time is the thing that distinguishes the D code from the C++ code; it's the *whole point*... If I have to continue to generate tables offline and paste big tables of data in the sourc

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

On 24 March 2018 at 00:04, Jonathan M Davis via Digitalmars-d wrote: > On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d > wrote: >> On 03/23/2018 07:46 PM, Jonathan M Davis wrote: >> > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d > wrote: >> >> It nev

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

On Saturday, March 24, 2018 01:37:10 Nick Sabalausky via Digitalmars-d wrote: > On 03/23/2018 07:46 PM, Jonathan M Davis wrote: > > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: > >> It never made any sense to me that there could be any problem > >> with the compile