Re: Policy-based design in D

Dne 14.2.2017 v 07:48 TheGag96 via Digitalmars-d-learn napsal(a): https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate validation on dpaste fails right now?) Because certificate is expired, dpaste use certs from Lets Encrypt which has short time of validity I have same issue

Re: A New Import Idiom`

On Tuesday, 14 February 2017 at 02:32:33 UTC, Jerry wrote: On Monday, 13 February 2017 at 22:40:55 UTC, Ali Çehreli wrote: On 02/13/2017 06:28 AM, Mike Parker wrote: https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ I claimed there is a performance improvement

Policy-based design in D

Tonight I stumbled upon Andrei's concept of policy-based design (https://en.wikipedia.org/wiki/Policy-based_design) and tried to implement their example in D with the lack of multiple inheritance in mind. https://dpaste.dzfl.pl/adc05892344f (btw, any reason why certificate validation on

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

`#std.stdio.File` doesn't work, we don't know where is the module separator: that could mean `module std` with a class stdio with a field File. so the syntax would have be: `std.stdio SYMBOL File` frankly I don't care which symbol, so long it looks like that. And as I said, `std.stdio::File` is

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

Should d runtime catch SIGFPE and throw an exception?

As I know, native languages like rust, go, pony, crystal all can recover from dividing zero fault.

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

as for language change, I believe the proposed syntax (`::`) can be reduced to a minimum if we we make `fullyqualifiedName` `::` a reduction to the from/Module inline import idiom. No complex corner case or new bug introduced, it could be done as a pure AST transformation On Mon, Feb 13, 2017 at

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

> The only thing from has going for it is that it doesn't require a language change. Yours does, so it should be compared to the proposals in DIP1005 and not just from. indeed. But just because something can be done in library code doesn't mean it should. Same exact rationale for: `lazy`, `=>`,

Re: syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

On Tuesday, 14 February 2017 at 03:49:28 UTC, Timothee Cour wrote: What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

[Issue 17169] New default ddoc theme merges all paragraphs except the first

https://issues.dlang.org/show_bug.cgi?id=17169 --- Comment #3 from Nick Sabalausky --- P1 is in a separate "Summary" div further up from the Description div shown here. This, I understand, is intentional as the first paragraph is considered to be the "summary", and

syntax sugar: std.path::buildPath instead of from!"std.path".buildPath

What about allowing syntax sugar as an alternative to relying on the new `from/Module` inline import idiom: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void fun(T)(Module!"std.stdio".File input, T value) if

[Issue 17180] New: to!string('\0') makes "\0" which breaks concatination

https://issues.dlang.org/show_bug.cgi?id=17180 Issue ID: 17180 Summary: to!string('\0') makes "\0" which breaks concatination Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major

Re: creating a temporary fifo (tmpfile but for fifo)

On 2/13/17 12:12 PM, Paul Backus wrote: On Sunday, 12 February 2017 at 11:47:26 UTC, Timothee Cour wrote: * std.stdio.tempfile creates an (unnamed) File. How do I create a temporary fifo instead? my workaround is to use tempnam but docs says it's not recommended (

Re: A New Import Idiom`

On Monday, 13 February 2017 at 22:40:55 UTC, Ali Çehreli wrote: On 02/13/2017 06:28 AM, Mike Parker wrote: https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ I claimed there is a performance improvement in compilation. Can someone answer kibwen's question on this

[Issue 17169] New default ddoc theme merges all paragraphs except the first

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

Re: Alias type with different initialiser.

On Monday, 13 February 2017 at 22:59:11 UTC, John Colvin wrote: [ snip ] sorry, made a typo, that should have been alias int1 = Initial!(int, 1); static assert(int1.initial == 1); // typeof(int1.initial) == int static assert(int1.init == 1); // typeof(int1.init) == int1

Re: Creating an array of immutable objects

On 02/13/2017 04:59 PM, David Zhang wrote: I have a struct with two immutable members, and I want to make an array of them. How do I to this? I'm using allocators for this. I realize that I misunderstood you; see below for a mutable array. The following code produces an immutable array

Creating an array of immutable objects

Hi, I have a struct with two immutable members, and I want to make an array of them. How do I to this? I'm using allocators for this. string[] paths; struct FileDesc { immutable string path; immutable uint index; } _fileDesc = /*something*/; You can't use alloc.makeArray because it

Re: Best error msg ever

On Mon, 13 Feb 2017 15:09:31 +, Kagamin wrote: > On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote: >> "References cannot be upcast to the enclosing class object, nor can >> they be downcast to a derived interface." >> >> https://dlang.org/spec/interface.html#com-interfaces > >

Re: Vibrant 2.0, major update

On Monday, 13 February 2017 at 22:57:18 UTC, Ali Çehreli wrote: All interesting stuff! Look how much interest the self-important idiom received, which the original author had thought to be a trivial matter: I hear you but for digital consumer products the driver of sales is from what

Re: Vibrant 2.0, major update

On 02/13/2017 02:18 PM, Guillaume Piolat wrote: > https://www.auburnsounds.com/blog/2017-02-13_Vibrant-2.0-released-free-demo.html > > > There is nothing terribly interesting to say technically. I disagree because you've already given interesting details like the following and you said

Re: Alias type with different initialiser.

On Monday, 13 February 2017 at 22:16:36 UTC, Bastiaan Veelo wrote: On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote: https://dlang.org/phobos/std_typecons.html#.Typedef Thanks for the pointers. Both Typedef and Proxy create types that don't mix with the base type, which I want

Re: vibe.d 0.8.0 and 0.7.31 beta releases

On Wednesday, 1 February 2017 at 14:01:39 UTC, Sönke Ludwig wrote: Am 01.02.2017 um 10:46 schrieb aberba: On Wednesday, 1 February 2017 at 09:35:02 UTC, Sönke Ludwig wrote: Am 31.01.2017 um 12:11 schrieb Sönke Ludwig: The first release of the revamped core module [1] is nearing, and along

Re: A New Import Idiom`

On 02/13/2017 06:28 AM, Mike Parker wrote: https://www.reddit.com/r/programming/comments/5tt33y/a_new_import_idiom_for_d/ I claimed there is a performance improvement in compilation. Can someone answer kibwen's question on this subthread please:

Re: Vibrant 2.0, major update

On Monday, 13 February 2017 at 21:42:12 UTC, Ali Çehreli wrote: Typo: "I didn't expected" This was fixed after the video was uploaded and tagged so I kept it :| Have you already written a blog about developing this game? ;) Ali Thanks for the interest! v2.0:

Re: Alias type with different initialiser.

On Monday, 13 February 2017 at 16:40:02 UTC, Daniel Kozak wrote: https://dlang.org/phobos/std_typecons.html#.Typedef Thanks for the pointers. Both Typedef and Proxy create types that don't mix with the base type, which I want to the contrary. So I guess I'll go with struct Initial(T, T

Re: Vibrant 2.0, major update

On 02/13/2017 06:22 AM, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. And this one update is pretty major: levels, asteroids, storyline, game modes... everything changed, everything went under scrutiny. Now using LDC 1.1.0 and supporting Windows, Mac and

Re: Vibrant 2.0, major update

On Monday, 13 February 2017 at 19:46:42 UTC, Jacob Carlborg wrote: On 2017-02-13 15:22, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. And this one update is pretty major: levels, asteroids, storyline, game modes... everything changed, everything went under

[Issue 17169] New default ddoc theme merges all paragraphs except the first

https://issues.dlang.org/show_bug.cgi?id=17169 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com --- Comment #1

Re: A New Import Idiom`

On Monday, 13 February 2017 at 21:04:05 UTC, Johan Engelen wrote: On Monday, 13 February 2017 at 20:09:45 UTC, Daniel Nielsen wrote: I still suspect there will be a difference in real-world applications even with LDC. Why would you expect there to be a difference? Module ctors/dtors are

Re: CTFE Status

On Monday, 13 February 2017 at 12:26:14 UTC, Stefan Koch wrote: I am currently working on && again, So far I hit a curious situation when handling (b1 && b2 && b3) everything works fine except that b3 will be evaluated 3 times. It's a puzzler :) I just reverted every change of last week I

Re: A New Import Idiom`

On Monday, 13 February 2017 at 20:09:45 UTC, Daniel Nielsen wrote: I still suspect there will be a difference in real-world applications even with LDC. Why would you expect there to be a difference? Module ctors/dtors are still pulled in, regardless of the import being selective or not.

[Issue 17177] AutoImplement fails on function overload sets with "cannot infer type from overloaded function symbol"

https://issues.dlang.org/show_bug.cgi?id=17177 --- Comment #1 from alexandru.ermic...@gmail.com --- I have made a pull request for this bug: https://github.com/dlang/phobos/pull/5119 The problem was in generation of "parent" symbol for body code, that denoted the super.overridenMember. In

Re: A New Import Idiom`

On Monday, 13 February 2017 at 19:41:11 UTC, Johan Engelen wrote: But for a full program, compile time is the same (it's really short so you can't really conclude much from it), and binary size as well (LDC 1.1.0, -O3). For my test cases below, the binaries are identical, except for around 30

Re: Vibrant 2.0, major update

On 2017-02-13 15:22, Guillaume Piolat wrote: It's the 10th update for this abstract shooter made in D. And this one update is pretty major: levels, asteroids, storyline, game modes... everything changed, everything went under scrutiny. Now using LDC 1.1.0 and supporting Windows, Mac and Linux

Re: A New Import Idiom`

On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post ... [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I also liked the post, nicely written. I didn't check, but if this idiom is not already tested in dmd-testsuite, please add it!

Re: A New Import Idiom`

On Monday, 13 February 2017 at 15:04:53 UTC, Daniel N wrote: On Monday, 13 February 2017 at 15:00:24 UTC, jmh530 wrote: With the Jack Stouffer comparison, wouldn't it be fairer to do: import std.datetime : Systime; import std.traits : isIntegral; Probably, please help measuring your idea

Re: Name That Technique!

On 02/07/2017 04:28 PM, deadalnix wrote: On Saturday, 4 February 2017 at 23:54:12 UTC, David Gileadi wrote: That's obviously a self important lookup. This. So much this. I'm afraid you are the only one who appreciate my humor :) "self-important" is official now:

[Issue 17179] New: dmd 2.073 betas segfault while trying to build vibe.d project

https://issues.dlang.org/show_bug.cgi?id=17179 Issue ID: 17179 Summary: dmd 2.073 betas segfault while trying to build vibe.d project Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW

Re: Mallocator and 'shared'

On Monday, 13 February 2017 at 14:20:05 UTC, Kagamin wrote: Thread unsafe methods shouldn't be marked shared, it doesn't make sense. If you don't want to provide thread-safe interface, don't mark methods as shared, so they will not be callable on a shared instance and thus the user will be

Re: creating a temporary fifo (tmpfile but for fifo)

On Sunday, 12 February 2017 at 11:47:26 UTC, Timothee Cour wrote: * std.stdio.tempfile creates an (unnamed) File. How do I create a temporary fifo instead? my workaround is to use tempnam but docs says it's not recommended ( http://man7.org/linux/man-pages/man3/tempnam.3.html) I believe the

Re: A New Import Idiom`

On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/ An entertaining read!

Re: Alias type with different initialiser.

Dne 13.2.2017 v 17:40 Daniel Kozak napsal(a): Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a): Hi, In Extended Pascal, you can derive from a basic type and change the default initialiser like so: type int1 = integer value 1; var i : int1; ii : int1 value

Re: A New Import Idiom`

On Monday, 13 February 2017 at 16:17:49 UTC, jmh530 wrote: So I tried it again comparing all three versions on my machine. This time I didn't notice a difference in compilation speed or binary size between the version with import std.datetime; import std.traits; and the one with import

Re: Alias type with different initialiser.

Dne 13.2.2017 v 16:28 Bastiaan Veelo via Digitalmars-d-learn napsal(a): Hi, In Extended Pascal, you can derive from a basic type and change the default initialiser like so: type int1 = integer value 1; var i : int1; ii : int1 value 2; assert(i = 1); assert(ii = 2); I have it

Re: A New Import Idiom`

On Monday, 13 February 2017 at 15:04:53 UTC, Daniel N wrote: Probably, please help measuring your idea and post it here. I intentionally chose a test made by someone else to avoid biasing from my part. It was the only test I found at time of writing. The first time I did it, I got a ~60%

Re: Munich D Meetup - February 14, 2017: D and the Cloud - D-Lovers Special

On Saturday, 4 February 2017 at 17:56:55 UTC, Stefan wrote: in 10 days will be our next Munich D Meetup. Would be awesome to welcome some of you there. Agenda: • 18:00: Get together with Pizza and beer • 18:45: D and the Cloud, by Ozan • 19:30: Short Break • 19:40: Usage of the D Compiler in

Alias type with different initialiser.

Hi, In Extended Pascal, you can derive from a basic type and change the default initialiser like so: type int1 = integer value 1; var i : int1; ii : int1 value 2; assert(i = 1); assert(ii = 2); I have it working in D, but it seems a little clumsy. Is there a better way?

Beta D 2.073.1-b2

Second beta for the 2.073.1 point release. This version resolves a few regressions and bugs in the 2.073.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.073.1.html Please report any bugs at https://issues.dlang.org -Martin

Re: Best error msg ever

On Monday, 13 February 2017 at 14:46:38 UTC, Mike Parker wrote: "References cannot be upcast to the enclosing class object, nor can they be downcast to a derived interface." https://dlang.org/spec/interface.html#com-interfaces COM interfaces can't be downcasted indeed, but it should be

Re: A New Import Idiom`

On Monday, 13 February 2017 at 15:00:24 UTC, jmh530 wrote: On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post describing the import idiom that came to light in a recent forum discussion regarding DIP 1005 [3]. The relevant links are at [1] and

Re: A New Import Idiom`

On Monday, 13 February 2017 at 14:28:20 UTC, Mike Parker wrote: Daniel Nielsen put together a post describing the import idiom that came to light in a recent forum discussion regarding DIP 1005 [3]. The relevant links are at [1] and [2]. [1]

Re: Best error msg ever

On Monday, 13 February 2017 at 13:38:23 UTC, Kagamin wrote: On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote: and I guess even ComObject does not inherit from Object This compiles: void f() { import core.sys.windows.com; ComObject a; Object b=a; }

Vibrant 2.0, major update

It's the 10th update for this abstract shooter made in D. And this one update is pretty major: levels, asteroids, storyline, game modes... everything changed, everything went under scrutiny. Now using LDC 1.1.0 and supporting Windows, Mac and Linux x86_64 (tested: Debian and Ubuntu).

A New Import Idiom`

Daniel Nielsen put together a post describing the import idiom that came to light in a recent forum discussion regarding DIP 1005 [3]. The relevant links are at [1] and [2]. [1] https://dlang.org/blog/2017/02/13/a-new-import-idiom/ [2]

Re: Mallocator and 'shared'

On Sunday, 12 February 2017 at 20:08:05 UTC, bitwise wrote: Given that both the data and the method are 'shared', a caller should know that race conditions are possible and that they should aquire a lock before accessing either of them...or so it would seem. Thread unsafe methods shouldn't

Re: Best error msg ever

On Monday, 13 February 2017 at 13:21:44 UTC, Daniel Kozak wrote: and I guess even ComObject does not inherit from Object This compiles: void f() { import core.sys.windows.com; ComObject a; Object b=a; }

Re: Best error msg ever

On Monday, 13 February 2017 at 13:18:33 UTC, Daniel Kozak wrote: Not all classes, extern(C++) classes does not C++ only has C++ interfaces and they are different from D interfaces.

Re: Best error msg ever

Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a): On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote: not all interfaces are Objects Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object. and I guess even

Re: Best error msg ever

Dne 13.2.2017 v 14:12 Kagamin via Digitalmars-d napsal(a): On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote: not all interfaces are Objects Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object. Not all classes,

Re: Best error msg ever

On Saturday, 11 February 2017 at 05:19:37 UTC, Walter Bright wrote: not all interfaces are Objects Do you have an example? How it can be? Only classes can implement interfaces, and classes inherit from Object.

[Issue 17178] namespace bar.std conflicts with namespace bar.std

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

[Issue 13183] C++ namespace should not conflict with import root package

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

Re: CTFE Status

I am currently working on && again, So far I hit a curious situation when handling (b1 && b2 && b3) everything works fine except that b3 will be evaluated 3 times. It's a puzzler :)

Berlin D Meetup February 2017

Hi All, The Berlin February D meetup is happening this Friday (17th) at 19:30 at Berlin Co-Op (http://co-up.de/) on the fifth floor. Mihails Strasuns will be presenting a talk on "Testing D projects with GitLab CI and Docker" and a brief introductions is below. "Hobby projects often

Re: Codecov and CyberShadow failure

On Sunday, 12 February 2017 at 15:30:40 UTC, Vladimir Panteleev wrote: I accept that this shouldn't have taken a week to fix, and the initial change in question (tmpfs move) would have been better done in a test environment. FWIW, in parallel I've been working on a full-disk backup strategy to

Re: can't use extern(C++,std) in a module that imports std.whatever

On Monday, 13 February 2017 at 08:21:38 UTC, Timothee Cour wrote: https://issues.dlang.org/show_bug.cgi?id=17178 dmd -c -o- bar.d Error: namespace bar.std conflicts with import bar.std at bar.d(2) ``` module bar; import std.exception; extern (C++, std) { struct Foo1 { } } ``` this seems

can't use extern(C++,std) in a module that imports std.whatever

https://issues.dlang.org/show_bug.cgi?id=17178 dmd -c -o- bar.d Error: namespace bar.std conflicts with import bar.std at bar.d(2) ``` module bar; import std.exception; extern (C++, std) { struct Foo1 { } } ``` this seems like a serious blocker to interface with C++ ; what's a workaround?

[Issue 17178] namespace bar.std conflicts with namespace bar.std

https://issues.dlang.org/show_bug.cgi?id=17178 Timothee Cour changed: What|Removed |Added CC|

[Issue 17178] New: namespace bar.std conflicts with namespace bar.std

https://issues.dlang.org/show_bug.cgi?id=17178 Issue ID: 17178 Summary: namespace bar.std conflicts with namespace bar.std Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: blocker