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

On 2017-02-16 01:40, John Colvin wrote: Slightly OT, but it is related so bear with me: Design by introspection is great and prevent having to make new names for every possible combo of features. Unfortunately, it doesn't work so well for introspecting multiple types at once: normally you have

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

On 2017-02-16 01:37, ZombineDev wrote: BTW, shouldn't we use `enum`, instead of `auto`, since everywhere else `enum` means guaranteed to be computed at compile-time whereas `auto` means the opposite? Far enough, since it's not possible to change the parameter inside the function anyway.

[Issue 17189] New: Include byPair in the associative array document

https://issues.dlang.org/show_bug.cgi?id=17189 Issue ID: 17189 Summary: Include byPair in the associative array document Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: enhancement

Re: .byKeyValue should probably return a Tuple

On Thu, Feb 16, 2017 at 05:02:41AM +, Yuxuan Shui via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 22:02:01 UTC, Seb wrote: > > On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui wrote: > > > for(k, v; aa) { ... } is better than: > > > > > > for(o; aa) { > > > auto k

Re: D future ...

Jack Stouffer wrote: Can you please make a bug with a level of regression for your specific problem? yeah. https://issues.dlang.org/show_bug.cgi?id=17188

Re: .byKeyValue should probably return a Tuple

On Wednesday, 15 February 2017 at 22:02:01 UTC, Seb wrote: On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui wrote: for(k, v; aa) { ... } is better than: for(o; aa) { auto k = o.key, v = o.value; ... } right? Are there any reason why .byKeyValue doesn't return a Tuple?

[Issue 17188] `core.stdc.stdlib.qsort()` is broken

https://issues.dlang.org/show_bug.cgi?id=17188 Ketmar Dark changed: What|Removed |Added CC|

[Issue 17188] New: `core.stdc.stdlib.qsort()` is broken

https://issues.dlang.org/show_bug.cgi?id=17188 Issue ID: 17188 Summary: `core.stdc.stdlib.qsort()` is broken Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority:

Re: D future ...

On Thursday, 16 February 2017 at 03:46:29 UTC, ketmar wrote: you want the example? `scope` was added to `_compare_fp_t`from "core.stdc.stdlib". thank you for breaking ALL my code thatis using `qsort()`. i guess nobody from core dev team really used`qsort()` from libc, so it is ok to break the

Re: opApply with Type Inference and Templates?

On Thursday, 16 February 2017 at 03:20:12 UTC, Jerry wrote: I am trying to do opApply to work when the delegate passed when it is and isn't nogc/nothrow. As soon as you involve a template though, type inference goes out the door. I want to be able to use opApply with templates (to get the auto

Re: D future ...

Jack Stouffer wrote: And I sincerely hope they work to fix them before adding in a bunch of new DIPs which will further complicate matters, especially with regard to function signitures. so far i see that they just like to say: "we won't break user's code", and then silently breaking it,

opApply with Type Inference and Templates?

I am trying to do opApply to work when the delegate passed when it is and isn't nogc/nothrow. As soon as you involve a template though, type inference goes out the door. I want to be able to use opApply with templates (to get the auto @nogc/nothrow deducation passed on the delegate passed) but

Re: User imput string int and float[DOUBT]

On 02/15/2017 05:49 PM, Jean Cesar wrote: > So I'm a beginner in this language and have very little time I started > I'm interested in apprehending concepts of object orientation > polymorphism inheritance, multiple inheritance as in c ++ D is similar to C++ but also very different. > but I

Re: User imput string int and float[DOUBT]

On Wednesday, 15 February 2017 at 23:40:41 UTC, Ali Çehreli wrote: On 02/15/2017 03:20 PM, Jean Cesar wrote: How do I make a class person where I use set and get methods to imput the user type: I have some information here: http://ddili.org/ders/d.en/input.html You should also know how

Re: Declaring constant references in struct members

On Thursday, 16 February 2017 at 01:05:58 UTC, David Zhang wrote: Is there a similar mechanism for one struct holding another? You'd have to make the member a pointer to the struct. immutable(B)* b;

Re: Declaring constant references in struct members

On Thursday, 16 February 2017 at 00:49:45 UTC, Adam D. Ruppe wrote: On Thursday, 16 February 2017 at 00:43:30 UTC, David Zhang wrote: struct S { O object; } import std.typecons; Rebindable!O object; http://dpldocs.info/experimental-docs/std.typecons.Rebindable.html Is there a similar

Re: Declaring constant references in struct members

On Thu, Feb 16, 2017 at 12:43:30AM +, David Zhang via Digitalmars-d-learn wrote: > Hi, > > Say I have a struct S that holds a reference to an object O. Is there > a way to express that I want to be able to change the reference, but > not what the reference points to? Thanks. > > struct S {

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

On Thursday, 16 February 2017 at 00:37:00 UTC, ZombineDev wrote: On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright wrote: On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight.

Re: Declaring constant references in struct members

On Thursday, 16 February 2017 at 00:43:30 UTC, David Zhang wrote: struct S { O object; } import std.typecons; Rebindable!O object; http://dpldocs.info/experimental-docs/std.typecons.Rebindable.html

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

On Wednesday, 15 February 2017 at 19:39:52 UTC, Andrei Alexandrescu wrote: On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break =>

Declaring constant references in struct members

Hi, Say I have a struct S that holds a reference to an object O. Is there a way to express that I want to be able to change the reference, but not what the reference points to? Thanks. struct S { O object; } class O { size_t things. }

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

On Thursday, 16 February 2017 at 00:08:12 UTC, Walter Bright wrote: On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight. We just never thought of it. What do you think about

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

On 2/15/2017 12:31 PM, Jonathan M Davis via Digitalmars-d wrote: It's one of those features that I was surprised when you couldn't do it. It was an oversight. We just never thought of it.

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

Also, as mentioned in the std.algorithm.mutation.remove case, constraints in Phobos often confuse "requirements" with "specializations". Requirements should be user-facing constraints, while specializations are implementation details better handled with internal static if.

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

On 2/15/2017 1:24 PM, Jonathan M Davis via Digitalmars-d wrote: So, regardless of the exact terminology, we have a whole set of very similar but subtly different traits. And as it stands, they _will_ get screwed up unless someone is carefully looking at each to make sure that they actually use

Re: User imput string int and float[DOUBT]

On 02/15/2017 03:20 PM, Jean Cesar wrote: How do I make a class person where I use set and get methods to imput the user type: I have some information here: http://ddili.org/ders/d.en/input.html You should also know how to read strings: http://ddili.org/ders/d.en/strings.html And this

Re: Convert call to a string

On Wednesday, 15 February 2017 at 22:07:22 UTC, data pulverizer wrote: That's great, thanks both of you!

User imput string int and float[DOUBT]

How do I make a class person where I use set and get methods to imput the user type: Import std.stdio; class person { private: string name, address; int age; float height; public: void setNome() { write("Enter Your Name:"); // the problem is here how am I going to read the

Re: Convert call to a string

On Wed, Feb 15, 2017 at 10:58:42PM +, ag0aep6g via Digitalmars-d-learn wrote: > On Wednesday, 15 February 2017 at 22:34:22 UTC, H. S. Teoh wrote: > > auto debugPrint(alias fun, A...)(A args) { > > writefln("%s(%(%s, %))", __traits(identifier, fun), [args]); > >

Re: Convert call to a string

On Wednesday, 15 February 2017 at 22:34:22 UTC, H. S. Teoh wrote: auto debugPrint(alias fun, A...)(A args) { writefln("%s(%(%s, %))", __traits(identifier, fun), [args]); return fun(args); } string arg = "hello"; string myCall =

Re: D future ...

On Wednesday, 15 February 2017 at 21:46:32 UTC, bpr wrote: You're missing what I consider to be 'the Big Picture', namely that Swift will become popular on non-Apple platforms, and it needs to be fairly capable to compete with Go, Java, and C++, and others. IBM is already backing server side

Re: Convert call to a string

On Wed, Feb 15, 2017 at 02:18:48PM -0800, H. S. Teoh via Digitalmars-d-learn wrote: [...] > Try this: > > auto debugPrint(string expr)() { > writeln(expr); > return mixin(expr); > } > > string myCall = debugPrint!`someFunction(1, "hello")`; [...]

Re: Convert call to a string

On Wed, Feb 15, 2017 at 10:07:22PM +, data pulverizer via Digitalmars-d-learn wrote: > I'd like to convert a call to a string for debug printing purposes for > example: > > > ``` > import std.stdio : writeln; > void someFunction(int x, string y){} > string myCall =

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

On 02/15/2017 03:31 PM, Jonathan M Davis via Digitalmars-d wrote: On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an

Convert call to a string

I'd like to convert a call to a string for debug printing purposes for example: ``` import std.stdio : writeln; void someFunction(int x, string y){} string myCall = debugPrint(someFunction(1, "hello")); writeln(myCall); ``` writes: someFunction(1, "hello") Does this functionality exists? If

Re: .byKeyValue should probably return a Tuple

On Wednesday, 15 February 2017 at 21:54:20 UTC, Yuxuan Shui wrote: for(k, v; aa) { ... } is better than: for(o; aa) { auto k = o.key, v = o.value; ... } right? Are there any reason why .byKeyValue doesn't return a Tuple? There's byPair (http://dlang.org/phobos/std_array.html#byPair)

.byKeyValue should probably return a Tuple

for(k, v; aa) { ... } is better than: for(o; aa) { auto k = o.key, v = o.value; ... } right? Are there any reason why .byKeyValue doesn't return a Tuple?

Re: D future ...

On Wednesday, 15 February 2017 at 21:16:51 UTC, Meta wrote: Isn't that a little uncharitable? I just spent about 20 minutes list out all of my problems with the language, and how somethings are pretty broken. But I deleted it and I'm not going to post it. It was just another rant. One that

Re: D future ...

On Wednesday, 15 February 2017 at 17:53:43 UTC, Ola Fosheim Grøstad wrote: Typo: I mean't that one cannot assume that Apple hardware has more than 2 cores (so one has to write applications that perform well with only 2 cores). You're missing what I consider to be 'the Big Picture', namely

Re: Get the address of an object, within the object itself

On Wednesday, 15 February 2017 at 21:37:12 UTC, Jonathan M Davis wrote: On Wednesday, February 15, 2017 13:33:23 Jonathan M Davis via Digitalmars-d- learn wrote: On Wednesday, February 15, 2017 21:27:00 Andrew Chapman via Digitalmars-d- learn wrote: > Hi all, sorry if this question is silly,

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

On Wed, Feb 15, 2017 at 09:03:46PM +, Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: > > I'd like to take a step back and devise a consistent taxonomy of these > > things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow

Re: Get the address of an object, within the object itself

On Wednesday, February 15, 2017 13:33:23 Jonathan M Davis via Digitalmars-d- learn wrote: > On Wednesday, February 15, 2017 21:27:00 Andrew Chapman via Digitalmars-d- > learn wrote: > > Hi all, sorry if this question is silly, but is it possible to > > get the address of an object within the

Re: Get the address of an object, within the object itself

On Wednesday, February 15, 2017 21:27:00 Andrew Chapman via Digitalmars-d- learn wrote: > Hi all, sorry if this question is silly, but is it possible to > get the address of an object within the object itself? > > e.g. > > class Node > { > this() > { > writeln(); // Doesn't

Get the address of an object, within the object itself

Hi all, sorry if this question is silly, but is it possible to get the address of an object within the object itself? e.g. class Node { this() { writeln(); // Doesn't work } } auto node = new Node(); writeln(); // Does work Thanks very much, Cheers, Andrew.

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

On 2/15/2017 1:03 PM, Jack Stouffer wrote: On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3.

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

On Wednesday, February 15, 2017 21:03:46 Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright > > wrote: > > I'd like to take a step back and devise a consistent taxonomy > > of these things > > Ok > > > 1. auto decoding dynamic arrays > > Narrow

[Issue 17186] Type inference for parameters with default argument

https://issues.dlang.org/show_bug.cgi?id=17186 Walter Bright changed: What|Removed |Added Keywords||preapproved

Re: Announcement: DConf 2017 Hackathon May 7

On 02/14/2017 01:17 PM, Walter Bright wrote: I am happy to announce that there will be a special addition to this year's DConf. Can we have dconf.org updated with this please. Ali

Re: D future ...

On Wednesday, 15 February 2017 at 20:53:58 UTC, Jack Stouffer wrote: On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. This is what Manu and deadalnix have been saying for the

Re: D future ...

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. +1

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

On Wednesday, 15 February 2017 at 20:54:02 UTC, Walter Bright wrote: I'd like to take a step back and devise a consistent taxonomy of these things Ok 1. auto decoding dynamic arrays Narrow strings 2. not auto decoding arrays Wide strings 3. static arrays Do these need to be called

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

Please fix your newsreader so it submits postings in text format, not html.

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

On Wednesday, February 15, 2017 12:54:02 Walter Bright via Digitalmars-d wrote: > On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: > > isStringLike. I wanted to add this for a while already. Please do! -- > > Andrei > What I've found messy and confusing with string overloads in Phobos is > there

Re: D future ...

On Wednesday, 15 February 2017 at 19:47:28 UTC, Cym13 wrote: There's little point in having more features if what's already there is half broken and not well-defined. This is what Manu and deadalnix have been saying for the past three years. Its fallen on deaf ears.

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

On 2/15/2017 10:51 AM, Andrei Alexandrescu wrote: isStringLike. I wanted to add this for a while already. Please do! -- Andrei What I've found messy and confusing with string overloads in Phobos is there are at least 6 kinds of strings: 1. auto decoding dynamic arrays 2. not auto decoding

Re: Questionnaire

On Wednesday, 8 February 2017 at 18:27:57 UTC, Ilya Yaroshenko wrote: 1. Why your company uses D? a. D is the best b. We like D c. I like D and my company allowed me to use D d. My head like D e. Because marketing reasons f. Because my company can be more efficient with D for some

[Issue 17185] Error: number '0x0.0123p-1022' is not representable

https://issues.dlang.org/show_bug.cgi?id=17185 --- Comment #3 from Sophie --- Note that one possible solution to this bug would be to use a custom strtold implementation rather than relying on the runtime. For reference, here is one such function implemented in native D

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

On Wednesday, February 15, 2017 14:30:02 Andrei Alexandrescu via Digitalmars-d wrote: > On 02/15/2017 02:22 PM, Jacob Carlborg wrote: > > On 2017-02-15 15:01, Andrei Alexandrescu wrote: > >> That's nice, could you please submit as an enhancement request on > >> bugzilla? > > > >

Re: Better than "Clock.currStdTime()/10000000"

On Wednesday, 15 February 2017 at 15:58:41 UTC, Jonathan M Davis wrote: [...] MonoTime before = MonoTime.currTime; Thread.sleep(dur!"msecs"(1000)); MonoTime after = MonoTime.currTime; Duration timeElapsed = after - before; writeln(timeElapsed); } ``` I get: "1 sec, 26

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

On Wednesday, 15 February 2017 at 20:09:46 UTC, Timothee Cour wrote: This thread completely diverged from the original post, which was propsing `::` instead of `from!`: ``` void fun(T)(std.stdio::File input, T value) if (std.traits::isIntegral!T) {...} ``` instead of: ``` void

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

On Wednesday, 15 February 2017 at 18:51:40 UTC, Andrei Alexandrescu wrote: On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos

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

This thread completely diverged from the original post, which was propsing `::` instead of `from!`: ``` 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 (Module!"std.traits".isIntegral!T)

[Issue 17187] Error when using std.format.unformatValue with static arrays

https://issues.dlang.org/show_bug.cgi?id=17187 --- Comment #1 from Jack Stouffer --- BTW this is a bug because this works auto str = "aaa"; auto spec = singleSpec("%s"); dchar[3] ret = ['a', 'a', 'a']; assert(str.unformatValue!(dchar[3])(spec) == ret); --

[Issue 17187] New: Error when using std.format.unformatValue with static arrays

https://issues.dlang.org/show_bug.cgi?id=17187 Issue ID: 17187 Summary: Error when using std.format.unformatValue with static arrays Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: A bug?

On Wednesday, 15 February 2017 at 16:11:36 UTC, drug wrote: No, you recursively call main() and get segfault (due to stack overflow) as expected I thought, that an stack overflow leeds to an exception. But that's not true, as I now see. Thanks for your answer.

Re: D future ...

On Wednesday, 15 February 2017 at 16:07:18 UTC, Ola Fosheim Grøstad wrote: I think Go has benefitted some from having limited and stable language semantics and continuously improving on the implementation. IMO that should make it attractive in the server space, i.e. you get low tooling-related

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

On 02/15/2017 06:20 AM, Daniel N wrote: On Wednesday, 15 February 2017 at 09:22:14 UTC, Daniel N wrote: template every(T...) { template satisfies(U...) { enum satisfies = true; } } (lunch-break => time to hack D!) template every(T...) { template satisfies(U...) {

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

On 02/15/2017 02:22 PM, Jacob Carlborg wrote: On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 Thanks. I'll take it up to Walter for preapproval. -- Andrei

[Issue 17186] Type inference for parameters with default argument

https://issues.dlang.org/show_bug.cgi?id=17186 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com

[Issue 17186] Type inference for parameters with default argument

https://issues.dlang.org/show_bug.cgi?id=17186 --- Comment #3 from Stefan Koch --- (In reply to Jacob Carlborg from comment #2) > It's already allowed for the return type. Which already wrecks havoc when trying to generate headers. --

[Issue 17186] Type inference for parameters with default argument

https://issues.dlang.org/show_bug.cgi?id=17186 --- Comment #2 from Jacob Carlborg --- It's already allowed for the return type. --

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

On 2017-02-15 15:01, Andrei Alexandrescu wrote: That's nice, could you please submit as an enhancement request on bugzilla? https://issues.dlang.org/show_bug.cgi?id=17186 -- /Jacob Carlborg

[Issue 17186] New: Type inference for parameters with default argument

https://issues.dlang.org/show_bug.cgi?id=17186 Issue ID: 17186 Summary: Type inference for parameters with default argument Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement

[Issue 17185] Error: number '0x0.0123p-1022' is not representable

https://issues.dlang.org/show_bug.cgi?id=17185 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com

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

On 02/15/2017 12:18 PM, Seb wrote: uint getAttributes(R)(R name) if (isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R) && !isConvertibleToString!R); Now as this same block is used > 30x in Phobos one could argue that it makes sense to use a convenience trait like:

Re: Getting a segfault here, why?

On Wednesday, 15 February 2017 at 18:19:18 UTC, aberba wrote: Trying to find it but working with a debugger in D is not straight forward. Not yo talk of interpretating the debugger output. On linux it is pretty easy. Just compile with `-g` to dmd and run the program in gdb. Run till it

Getting a segfault here, why?

I'm getting a segmentation fault in vibe.d web interface class. Does referring "this" in an "if" or "switch" within a method cause segfault? Trying to find it but working with a debugger in D is not straight forward. Not yo talk of interpretating the debugger output. How has things

[Issue 17185] Error: number '0x0.0123p-1022' is not representable

https://issues.dlang.org/show_bug.cgi?id=17185 --- Comment #1 from Sophie --- This occurred when compiling on ubuntu 12.04.04 --

Re: D future ...

On Wednesday, 15 February 2017 at 17:08:37 UTC, Ola Fosheim Grøstad wrote: modelling paradigm? One cannot really assume that Apple hardware has more than 2 CPUs. Typo: I mean't that one cannot assume that Apple hardware has more than 2 cores (so one has to write applications that perform

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

On Wednesday, 15 February 2017 at 17:18:15 UTC, Seb wrote: Now as this same block is used > 30x in Phobos That tells me you already have an empirical clear win! If you wrote exactly the same thing 30x inside the functions, you'd move it out to a new function too. if

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

On Wednesday, 15 February 2017 at 16:20:30 UTC, Chris Wright wrote: The greatest annoyance is if I have to read through several files of phobos sources just to figure out why there's no matching overload for this function call that looks right to me. I really really REALLY REALLY wish the

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

On Wednesday, 15 February 2017 at 17:10:26 UTC, Adam D. Ruppe wrote: On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We

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

https://issues.dlang.org/show_bug.cgi?id=17179 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com

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

On Wednesday, 15 February 2017 at 07:56:00 UTC, Jacob Carlborg wrote: Your documentation is an improvement but it doesn't help when reading the source code. Yeah, I think there's a few things we can do in the source too. We should find the common combinations and abstract them out, like I

Re: D future ...

On Wednesday, 15 February 2017 at 16:41:31 UTC, bpr wrote: Swift took over quickly because Apple has mandated it. While I'm happy about that, there's no denying that Swift wouldn't be where it is without the weight of Apple behind it. I'd go as far as to say that Swift's success is assured

[Issue 17185] New: Error: number '0x0.0123p-1022' is not representable

https://issues.dlang.org/show_bug.cgi?id=17185 Issue ID: 17185 Summary: Error: number '0x0.0123p-1022' is not representable Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: normal

Re: Vibrant 2.0, major update

On Wednesday, 15 February 2017 at 15:55:12 UTC, Steve Biedermann wrote: On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat wrote: Yeah, it isn't free anymore, but the first 15 levels are. I played it some time ago and, AFAIR, it was great. So I consider to buying it. But before I

Re: D future ...

On Wednesday, 15 February 2017 at 16:28:00 UTC, Jacob Carlborg wrote: On 2017-02-15 17:07, Ola Fosheim Grøstad wrote: This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms. TextMate on macOS is a native

Re: D future ...

On Wednesday, 15 February 2017 at 14:44:55 UTC, Ola Fosheim Grøstad wrote: Another example is Swift. Swift managed to take over Objective-C rather quickly IMO, but Swift has also absorbed the non-C semantics of Objective-C, thus it did not require changing existing practice significantly.

Re: D future ...

On 2017-02-15 17:07, Ola Fosheim Grøstad wrote: This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms. TextMate on macOS is a native macOS application (Cocoa, C++) but does not use Xcode to build, it's

Re: extern(C) and mangling type names

On Tue, 14 Feb 2017 20:51:43 -0800, Timothee Cour via Digitalmars-d wrote: Please configure your newsreader to use plain text. It appends HTML garbage to the end of your post.

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

On Wed, 15 Feb 2017 08:56:00 +0100, Jacob Carlborg wrote: > Your documentation is an improvement but it doesn't help when reading > the source code. For me, it almost entirely obviates reading the source code. I only need to read it if I'm trying to modify it, at which point I'm already

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

On Wed, 15 Feb 2017 05:28:11 +, Adam D. Ruppe wrote: > On Tuesday, 14 February 2017 at 20:46:17 UTC, Walter Bright wrote: >> A further improvement in the documentation would be to add links to >> isBidirectionalRange and hasLvalueElements. > > Kneel before your god! We're not worthy!

Re: A bug?

15.02.2017 19:00, berni пишет: I'm not sure if this is considered a bug: import std.stdio; import std.string; int c = 0; void main() { try { write(++c," "); stdout.flush(); int[10] tmp; throw new Exception(format("%s",tmp)); } finally {

Re: D future ...

On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder wrote: It is also "re-tribalising" around the Rust, Go, Swift, C++17 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM; ECMAScript, TypeScript, Elm in the browser, and Python in data science and such like. OK not

A bug?

I'm not sure if this is considered a bug: import std.stdio; import std.string; int c = 0; void main() { try { write(++c," "); stdout.flush(); int[10] tmp; throw new Exception(format("%s",tmp)); } finally { main(); } } Output: 1 2 3 4 5 6

Re: Vibrant 2.0, major update

On Monday, 13 February 2017 at 14:22:25 UTC, Guillaume Piolat wrote: Yeah, it isn't free anymore, but the first 15 levels are. I played it some time ago and, AFAIR, it was great. So I consider to buying it. But before I buy it, I have a question. Are updates included in the purchase or do I

Re: Better than "Clock.currStdTime()/10000000"

On Wednesday, February 15, 2017 16:27:34 drug via Digitalmars-d-learn wrote: > 15.02.2017 16:19, berni пишет: > > I need to measure time elapsed in seconds, like this: > >> auto start = Clock.currStdTime(); > >> // some stuff > >> auto stop = Clock.currStdTime(); > >> auto duration =

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

On Wednesday, February 15, 2017 14:35:40 Jack Stouffer via Digitalmars-d wrote: > On Wednesday, 15 February 2017 at 08:53:30 UTC, Jacob Carlborg > > wrote: > > "The static if feature recently proposed for C++ [1, 2] is > > fundamentally flawed, and its adoption would be a disaster for > > the

[Issue 9631] Error message not using fully qualified name when appropriate.

https://issues.dlang.org/show_bug.cgi?id=9631 Nick Treleaven changed: What|Removed |Added CC||destructiona...@gmail.com

  1   2   >