[Issue 18493] [betterC] Can't use aggregated type with postblit

https://issues.dlang.org/show_bug.cgi?id=18493 --- Comment #3 from Radu Racariu --- Declaring `C` as --- struct C { S s1; } --- makes the test case compile. --

Re: #dbugfix 18493

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote: On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote: On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493 From what I can gather

Re: Delegates and classes for custom code.

On Tuesday, 17 April 2018 at 04:09:57 UTC, Chris Katko wrote: I'm having trouble conceptualizing this issue at the moment. But it seems if I pass to the delegate my object, then I can ONLY use one class type. Can you post the code you're trying to run?

DConf and DIPs

With DConf for all of us and a short vacation for me just around the corner, I'm not going to be initiating any DIP reviews until mid-May. It's looking like the DIP, "Hooking D's struct move semantics" [1], will become DIP 1014 and I currently intend to launch the Community Review on May

Re: Delegates and classes for custom code.

I'm having trouble conceptualizing this issue at the moment. But it seems if I pass to the delegate my object, then I can ONLY use one class type. Say, the delegate takes a "this" from... some class that wants to have a dialog. A window. Now the delegate NEEDS a this from a window, and only

Re: Delegates and classes for custom code.

Some typos in there. execute == on_draw. Basically, I'm just sending a delegate/lambda "custom function" at initialization time. But I'd like that delegate to somehow access the holding classes functions. Or figure out how to do that. Maybe the class somehow sends the delegate a this

Delegates and classes for custom code.

What I want: class viewport_t { int x,y,w,h; } class dialog_t { int x,y; this( int x, int y, delegate void (viewport_t) on_draw ) { this.x = x; this.y = y; this.execute = execute; } void draw_text(string text) { } delegate void (viewport_t)

[Issue 18419] make all Phobos unittests version(StdUnittest)

https://issues.dlang.org/show_bug.cgi?id=18419 Nathan S. changed: What|Removed |Added Status|NEW |RESOLVED

Re: isInputRange is false for non-copyable types

This is going nowhere. Let's flesh this out face to face at dconf. Shachar On 16/04/18 12:01, Jonathan M Davis wrote: On Monday, April 16, 2018 07:15:36 Shachar Shemesh via Digitalmars-d wrote: On 16/04/18 01:28, Jonathan M Davis wrote: The fact that foreach copies the range that it's given

Re: Error calling geqrs function from lubeck package.

On Tuesday, 17 April 2018 at 03:26:25 UTC, Jamie wrote: Sorry it's really an error calling geqrs function from mir-lapack package.

Error calling geqrs function from lubeck package.

I'm attempting to use the lubeck package, as described here https://forum.dlang.org/post/axacgiisczwvygyef...@forum.dlang.org I have lubeck, mir-algorithm, mir-blas, mir-lapack downloaded and accessible by the compiler, and I have installed liblapack-dev and libblas-dev. When I attempt to

Re: (Unofficial) Discord Server!

On Monday, 16 April 2018 at 22:24:18 UTC, Luke Wilson wrote: Hi there! After having found nearly zero solutions for a D community on Discord, having one server be quite inefficient, I've made my own. https://discord.gg/crpA2Hn I hope to bring the community closer by doing this. I guess I

Re: #dbugfix 18493

On Tuesday, 17 April 2018 at 00:27:07 UTC, Nicholas Wilson wrote: It is odd though since void foo (){} extern(C) void main() { scope(exit) foo(); } compiles and runs with -betterC I believe `scope(exit)` is fine because it is basically try-finally, but `scope(failure)` won't work

Re: Feature to get or add value to an associative array.

On Tuesday, 17 April 2018 at 00:04:32 UTC, Cym13 wrote: auto value = ptr ? *ptr : *ptr = default; That is going to crash if ptr is null. is a new flag/method really that necessary? In my experience if you have trouble naming it you haven't found its true purpose yet. I think

Re: #dbugfix 18493

On Tuesday, 17 April 2018 at 00:08:07 UTC, Mike Franklin wrote: On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote: On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493 From what I can gather

Re: #dbugfix 18493

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote: On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493 From what I can gather this appears to be caused by a `scope(failure)` statement

Re: Feature to get or add value to an associative array.

On Monday, 16 April 2018 at 18:59:54 UTC, Giles Bathgate wrote: On Monday, 16 April 2018 at 12:41:07 UTC, JN wrote: It's only one additional "in", but makes the code more explicit and clear. I think in most cases, you will want to check if you are dealing with a fetched object or a default

[Issue 18768] object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

https://issues.dlang.org/show_bug.cgi?id=18768 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2166 --

[Issue 18767] __xtoHash memberwise hashing shouldn't just sum the member hashes

https://issues.dlang.org/show_bug.cgi?id=18767 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2166 --

(Unofficial) Discord Server!

Hi there! After having found nearly zero solutions for a D community on Discord, having one server be quite inefficient, I've made my own. https://discord.gg/crpA2Hn I hope to bring the community closer by doing this.

[Issue 18768] New: object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

https://issues.dlang.org/show_bug.cgi?id=18768 Issue ID: 18768 Summary: object.getArrayHash with custom toHash shouldn't just sum hashes of array elements Product: D Version: D2 Hardware: All OS: All

[Issue 18767] New: __xtoHash memberwise hashing shouldn't just sum the member hashes

https://issues.dlang.org/show_bug.cgi?id=18767 Issue ID: 18767 Summary: __xtoHash memberwise hashing shouldn't just sum the member hashes Product: D Version: D2 Hardware: All OS: All Status: NEW

[Issue 18766] std.typecons.Tuple.toHash could be improved

https://issues.dlang.org/show_bug.cgi?id=18766 Nathan S. changed: What|Removed |Added Severity|minor |enhancement --

[Issue 18766] std.typecons.Tuple.toHash could be improved

https://issues.dlang.org/show_bug.cgi?id=18766 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/phobos/pull/6457 --

[Issue 18766] New: std.typecons.Tuple.toHash could be improved

https://issues.dlang.org/show_bug.cgi?id=18766 Issue ID: 18766 Summary: std.typecons.Tuple.toHash could be improved Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor

Re: Feature to get or add value to an associative array.

On Sunday, 15 April 2018 at 22:55:41 UTC, Giles Bathgate wrote: On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote: I am proposing a new function called getOrAdd in I posted details of the PR here because at least 2 people do not like the name getOrAdd (and one of those people

Re: Building is slow!

I want to revisit this issue. Building 64 bit on Linux, release or debug, is fast. However, building 64 bit release on Windows 10 is super slow. I have a cross platform app that uses gtk-d. Today, I updated DMD to 2.079.1 and the gtk-d lib to 3.8.0. When I performed a debug build on Windows

Re: making a struct an inputRange with free functions

Am 16.04.2018 um 21:27 schrieb Jonathan M Davis: > On Monday, April 16, 2018 21:10:03 Johannes Loher via Digitalmars-d-learn > wrote: >> Is there a way to do this? Here is a naive implementation: >> https://run.dlang.io/is/JKvL80 . >> >> It does not pass `isInputRange` (I think, because the free

Re: making a struct an inputRange with free functions

On 4/16/18 3:10 PM, Johannes Loher wrote: Is there a way to do this? Here is a naive implementation: https://run.dlang.io/is/JKvL80 . It does not pass `isInputRange` (I think, because the free functions are not visible in the scope of `isInputRange`). You are correct, it's not possible.

Re: making a struct an inputRange with free functions

On Monday, April 16, 2018 21:10:03 Johannes Loher via Digitalmars-d-learn wrote: > Is there a way to do this? Here is a naive implementation: > https://run.dlang.io/is/JKvL80 . > > It does not pass `isInputRange` (I think, because the free functions are > not visible in the scope of

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

On Monday, April 16, 2018 19:01:02 Jack Stouffer via Digitalmars-d wrote: > On Monday, 16 April 2018 at 16:22:04 UTC, Jonathan M Davis wrote: > > Well, the reality of the matter is that if RefRange's opAssign > > doesn't work the way that it works, then RefRange is broken and > > fails at its

making a struct an inputRange with free functions

Is there a way to do this? Here is a naive implementation: https://run.dlang.io/is/JKvL80 . It does not pass `isInputRange` (I think, because the free functions are not visible in the scope of `isInputRange`). Trying to iterate over it with a foreach loop results in a compile error: Error:

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

On Monday, 16 April 2018 at 16:22:04 UTC, Jonathan M Davis wrote: Well, the reality of the matter is that if RefRange's opAssign doesn't work the way that it works, then RefRange is broken and fails at its purpose (and this is the designer of it speaking). So, if RefRange couldn't do what it's

Re: Feature to get or add value to an associative array.

On Monday, 16 April 2018 at 12:41:07 UTC, JN wrote: It's only one additional "in", but makes the code more explicit and clear. I think in most cases, you will want to check if you are dealing with a fetched object or a default created one, so that will complicate the function even further.

Re: Is DWT usable?

On 2018-04-16 06:24, dangbinghoo wrote: I have noticed DWT moved to as a dub package. And said it easy to startup. So, I just cloned the DWT git repo. And did the same thing as README. But I got the following : ``` dub --single main.d Performing "debug" build using /usr/bin/dmd for x86_64.

[Issue 18757] static invariant{} should either work or not be valid syntax

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

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 Walter Bright changed: What|Removed |Added CC|

Re: why use string for this example of appender?

Thanks all. I sometimes feel like Michael Corleone: "Just when I thought I was out, they pull me back in!" :) I realize it is not the place for it, but sometimes I wish the Library Reference explained things in terms of "why".

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #6 from FeepingCreature --- In my opinion, static this sets the precedent that static + class-level feature = module-level feature. --

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

On Monday, 16 April 2018 at 16:15:30 UTC, H. S. Teoh wrote: I could come up with some pretty pathological range types for stress-testing, if you want. (These are actual range types I've used in my own code, I didn't set out to break Phobos, but it turned out that Phobos makes many unstated

Podcast episode about anemic domain models (OOP vs procedural)

In 2016 I gave an online presentation for the Silicon Valley D Meetup about anemic domain models and D, but this presentation wasn't recorded (as far as I know). I have now published a podcast episode discussing that topic, going over the most important parts of the presentation.

Re: Issues with debugging GC-related crashes #2

On Monday, 16 April 2018 at 16:36:48 UTC, Matthias Klumpp wrote: [...] The code uses std.typecons.scoped occasionally, does no GC allocations in destructors and does nothing to mess with the GC in general. There are a few calls to GC.add/removeRoot in the gir-to-d generated code (ObjectG.d),

Re: How/where to hack DMD to generate docs for string mixed members.

On Monday, April 16, 2018 16:05:40 9il via Digitalmars-d-learn wrote: > On Sunday, 15 April 2018 at 08:17:21 UTC, Jonathan M Davis wrote: > > On Sunday, April 15, 2018 07:59:17 Stefan Koch via > > > > Digitalmars-d-learn wrote: > >> On Sunday, 15 April 2018 at 05:20:31 UTC, 9il wrote: > >> > Hey,

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

On Monday, April 16, 2018 15:58:34 Jack Stouffer via Digitalmars-d wrote: > 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

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

On Mon, Apr 16, 2018 at 03:58:34PM +, Jack Stouffer via Digitalmars-d wrote: [...] > In a perfect world, we'd have a pre-constructed test suite that people > could plug their range (with some data in it) into, where all the > tests make sure all Phobos assumptions hold true. [...] We could

Re: How/where to hack DMD to generate docs for string mixed members.

On Sunday, 15 April 2018 at 08:17:21 UTC, Jonathan M Davis wrote: On Sunday, April 15, 2018 07:59:17 Stefan Koch via Digitalmars-d-learn wrote: On Sunday, 15 April 2018 at 05:20:31 UTC, 9il wrote: > Hey, > > How/where to hack DMD to generate docs for string mixed > members? > > struct S > { >

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 Jonathan M Davis changed: What|Removed |Added CC|

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:

Re: How/where to hack DMD to generate docs for string mixed members.

On Sunday, 15 April 2018 at 07:59:17 UTC, Stefan Koch wrote: On Sunday, 15 April 2018 at 05:20:31 UTC, 9il wrote: Hey, How/where to hack DMD to generate docs for string mixed members? struct S { mixin(" /// auto bar() {} "); } Best regards, Ilya Yaroshenko hmm you

[Issue 18719] Doubly-called constructor against member when using forwarding constructors

https://issues.dlang.org/show_bug.cgi?id=18719 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18719] Doubly-called constructor against member when using forwarding constructors

https://issues.dlang.org/show_bug.cgi?id=18719 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/cbb49cb2591bd5aa3e5f9e0b8a4350cb04ec1206 Fix Issue 18719 - Doubly-called constructor against member

Re: PixelPerfectEngine v0.9.4-alpha.2

On Wednesday, 11 April 2018 at 21:44:57 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and

Re: why use string for this example of appender?

On 4/16/18 4:49 AM, Ali Çehreli wrote: On 04/15/2018 11:46 PM, WhatMeForget wrote: > > I think I got a handle on D's static and dynamic arrays, till I come to > std.array and see all the shiny new tools. I can understand all the > replace.. functions, but the appender function gave me pause.

Re: PixelPerfectEngine v0.9.4-alpha.2

On Wednesday, 11 April 2018 at 21:44:57 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/pixelperfectengine/releases/tag/v0.9.4-alpha.2 The editor is almost usable (still needs a way to import tiles from its own proprietary format), and now has a working, although still a bit slow and

Re: #include C headers in D code

On Monday, 16 April 2018 at 12:26:12 UTC, Jacob Carlborg wrote: On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote: You can use the C macros in the headers that you #include in your dpp file. dstep has a lot of code for translating macros. I don't want to translate macros at all,

[Issue 18762] DMD should use a unique path/filename for __stdin.o

for __stdin.o https://github.com/dlang/dmd/commit/bfb89f5099f4607d2b56a0508b3bbc6cec800de3 Merge pull request #8174 from CyberShadow/pull-20180416-133742 Fix Issue 18762 - DMD should use a unique path/filename for __stdin.o merged-on-behalf-of: Andrei Alexandrescu <andra...@users.noreply.github.com> --

[Issue 18762] DMD should use a unique path/filename for __stdin.o

https://issues.dlang.org/show_bug.cgi?id=18762 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #4 from RazvanN --- (In reply to uplink.coder from comment #3) > Well invariants cannot apply to static methods since they are only concerned > about the object's state. > which by definition cannot be directly

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 uplink.co...@googlemail.com changed: What|Removed |Added CC||uplink.co...@googlemail.com

Re: #dbugfix 18493

On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote: On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493 Noted!

Re: #dbugfix 18493

On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 --- Comment #2 from FeepingCreature --- In case 1, I maintain that this is a bug - the compiler should not smile-and-nod while silently ignoring syntax that hints at a semantic that does not apply. --

[Issue 18762] DMD should use a unique path/filename for __stdin.o

https://issues.dlang.org/show_bug.cgi?id=18762 Vladimir Panteleev changed: What|Removed |Added Keywords||pull

#dbugfix 18493

A blocker for more advanced 'betterC' usage.

Re: Feature to get or add value to an associative array.

On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote: Hi, I wanted a way to lazily insert a value into an associative array, and I am proposing a new function called getOrAdd in https://github.com/dlang/druntime/pull/2162 I am not sure if it's a good idea to combine accessor and

[Issue 18757] static invariant{} should either work or not be valid syntax

https://issues.dlang.org/show_bug.cgi?id=18757 RazvanN changed: What|Removed |Added CC|

Re: Feature to get or add value to an associative array.

On Monday, 16 April 2018 at 03:42:18 UTC, Jordan Wilson wrote: On Sunday, 15 April 2018 at 22:55:41 UTC, Giles Bathgate wrote: On Sunday, 15 April 2018 at 22:52:47 UTC, Giles Bathgate wrote: I am proposing a new function called getOrAdd in I posted details of the PR here because at least 2

Re: #include C headers in D code

On Monday, 16 April 2018 at 11:20:51 UTC, Atila Neves wrote: You can use the C macros in the headers that you #include in your dpp file. dstep has a lot of code for translating macros. I don't want to translate macros at all, but it's deeply intertwined with translating everything else.

Re: Is there a strong reason for Nullable's alias get this?

On Monday, 16 April 2018 at 10:10:56 UTC, FeepingCreature wrote: Nullable!T to T is a narrowing conversion, since T cannot express the null case. Therefor, it must not be implicit. I agree with this. To even reach for a Nullable type in one's codebase incurs a cost -- the need is substantial

[Issue 18736] constructor calls allowed after case labels

https://issues.dlang.org/show_bug.cgi?id=18736 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/15f525620895727147cf12e33596ae1a2d3ffa45 fix Issue 18736 - constructor calls allowed after case labels

Re: #include C headers in D code

On Saturday, 14 April 2018 at 04:07:12 UTC, Petar Kirov [ZombineDev] wrote: On Friday, 13 April 2018 at 10:31:43 UTC, Atila Neves wrote: On Wednesday, 11 April 2018 at 14:33:26 UTC, Jacob Carlborg wrote: On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

https://issues.dlang.org/show_bug.cgi?id=18472 --- Comment #10 from Mike Franklin --- PR 8173 seems to take care of the case... module betterc; enum b = typeid(size_t) is typeid(uint) ... but still fails for ... import std.format; import std.stdio; void main() { enum

Re: Is there a strong reason for Nullable's alias get this?

Addendum: The general principle is that a "narrowing conversion" should never be implicit. An example of a narrowing conversion is float to int, or int to short. In the case of integer types, D already follows this rule. Nullable!T to T is a narrowing conversion, since T cannot express the

Re: Is there a strong reason for Nullable's alias get this?

Say that we have a function that returns an int. We assign it to an auto variable and pass that to another function which takes an int. All is well. Say we change the function to return a Nullable!int. We expect the compiler to warn us that we must now check for isNull; however, what we

Re: #include C headers in D code

On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ The summary is that, modulo bugs, things like this work:

[Issue 18756] Escaping address of temporary struct field

https://issues.dlang.org/show_bug.cgi?id=18756 --- Comment #4 from Jonathan M Davis --- (In reply to anonymous4 from comment #3) > (In reply to Jonathan M Davis from comment #2) > > because it's always a bug. > It's correct when the result is passed to a function

Re: Is there a strong reason for Nullable's alias get this?

On Monday, April 16, 2018 08:34:13 FeepingCreature via Digitalmars-d wrote: > I think `alias get this` is a misfeature. > > If at all possible, compiletime errors should be preferred over > runtime errors. The point of Nullable is that the value contained > within may be absent. Considering the

Re: isInputRange is false for non-copyable types

On Monday, April 16, 2018 07:15:36 Shachar Shemesh via Digitalmars-d wrote: > On 16/04/18 01:28, Jonathan M Davis wrote: > > The fact that foreach copies the range that it's given makes using ref > > with anything other than arrays a bit of an iffy proposition. It will > > compile regardless of

Re: why use string for this example of appender?

On 04/15/2018 11:46 PM, WhatMeForget wrote: > > I think I got a handle on D's static and dynamic arrays, till I come to > std.array and see all the shiny new tools. I can understand all the > replace.. functions, but the appender function gave me pause. The > documentation says appender "Returns

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

https://issues.dlang.org/show_bug.cgi?id=18472 Mike Franklin changed: What|Removed |Added Keywords||pull --- Comment #9

The 10k Twitter Target

Lately, we've seen a steadily increasing trend of new followers on Twitter. We're closing in on the totally arbitrary yet emotionally significant number of 10,000. I was just thinking how cool it would be to hit that number before or during DConf. Now that my move is behind me and I'm

Is there a strong reason for Nullable's alias get this?

I think `alias get this` is a misfeature. If at all possible, compiletime errors should be preferred over runtime errors. The point of Nullable is that the value contained within may be absent. Considering the prevalence of type inference and UFCS chaining in idiomatic D, it is very possible

Re: Feature to get or add value to an associative array.

On Monday, 16 April 2018 at 03:42:18 UTC, Jordan Wilson wrote: I think Adding a Yes.add flag to the existing get makes sense That's an interesting idea. I forgot to mention that getOrAdd is a mutable function whereas get is inout, so that might also be problematic.

[Issue 18756] Escaping address of temporary struct field

https://issues.dlang.org/show_bug.cgi?id=18756 anonymous4 changed: What|Removed |Added Hardware|x86 |All

[Issue 18472] [Reg 2.078] betterC: cannot use format at compile time.

https://issues.dlang.org/show_bug.cgi?id=18472 --- Comment #8 from Mike Franklin --- (In reply to Rainer Schuetze from comment #7) > I think the main issue is that the compiler does not distinguish between > information needed at compile time and what's necessary inside the

why use string for this example of appender?

I think I got a handle on D's static and dynamic arrays, till I come to std.array and see all the shiny new tools. I can understand all the replace.. functions, but the appender function gave me pause. The documentation says appender "Returns a new Appender or RefAppender initialized with a

Re: lazy evaluation of logical operators in enum definition

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote: Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2);

Re: Small Buffer Optimization for string and friends

On Sunday, 8 April 2012 at 09:46:28 UTC, Vladimir Panteleev wrote: On Sunday, 8 April 2012 at 05:56:36 UTC, Andrei Alexandrescu wrote: Walter and I discussed today about using the small string optimization in string and other arrays of immutable small objects. On 64 bit machines, string

lazy evaluation of logical operators in enum definition

Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2); pragma(msg, prop!S3); When compiled, it produces: true false