Re: Github names & avatars

On Friday, 13 May 2016 at 17:19:01 UTC, Adam D. Ruppe wrote: Actually, given the blatant misogyny frequently on display on this forum, ???

Re: Official compiler

On Thursday, 25 February 2016 at 19:25:38 UTC, deadalnix wrote: On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote: If we would make GDC or LDC the official compiler then the next question which pops up is about compilation speed ldc is still significantly faster than clang,

Re: Official compiler

On Thursday, 25 February 2016 at 17:57:49 UTC, David Nadlinger wrote: I'm only playing devil's advocate because many people here make it seem as if there was no cost to supporting multiple compilers, while there most definitely is. This ranges from the blatant duplication of work over PR

Re: Official compiler

On Thursday, 25 February 2016 at 03:47:33 UTC, rsw0x wrote: On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe wrote: On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote: licensing issues I can't see any... Walter would be licensed to distribute all three. GDC is under

Re: Official compiler

On Thursday, 25 February 2016 at 03:26:54 UTC, Adam D. Ruppe wrote: On Thursday, 25 February 2016 at 03:16:57 UTC, rsw0x wrote: licensing issues I can't see any... Walter would be licensed to distribute all three. GDC is under GPL

Re: Official compiler

On Thursday, 25 February 2016 at 03:07:20 UTC, Puming wrote: On Thursday, 25 February 2016 at 02:48:24 UTC, Walter Bright wrote: [...] Maybe in the future, when ldc/gdc catches up versions with dmd, we can combine them into a bundle for downloads? Then new people can just download the

Re: Swift deprecate i++ and c-style for loop

On Wednesday, 24 February 2016 at 20:47:50 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 24 February 2016 at 18:06:19 UTC, Steven Schveighoffer wrote: I'm quite glad D stuck with the same type for arrays and array slices. And how will you get around this when not having a GC? Could you

Re: Head Const

On Wednesday, 24 February 2016 at 19:28:28 UTC, extrawurst wrote: On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves wrote: On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote: [...] I think that increasing language complexity for the sake of C++ integration is a

Re: [OT] Some neat ideas from the Kotlin language

On Tuesday, 23 February 2016 at 14:58:21 UTC, Xinok wrote: On Tuesday, 23 February 2016 at 07:18:09 UTC, rsw0x wrote: On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote: OTOH in the examples in Kotlin/Rust the variable 'var' changes its type from 'int?' to plain 'int'. In

Re: [OT] Some neat ideas from the Kotlin language

On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote: rsw0x wrote: On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller wrote: [...] D has this too, but only for nullable types afaik. if(byte* ptr = someFunc()){ //... } That's not quite the

Re: Disappointing inflexibility of argument passing with "alias this"

On Monday, 22 February 2016 at 18:11:58 UTC, H. S. Teoh wrote: On Mon, Feb 22, 2016 at 06:07:26PM +, rsw0x via Digitalmars-d wrote: On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote: >[...] explicitly-implicit constructors are badly needed, I could write an es

Re: Disappointing inflexibility of argument passing with "alias this"

On Monday, 22 February 2016 at 17:29:40 UTC, Adam D. Ruppe wrote: On Monday, 22 February 2016 at 17:22:51 UTC, Carl Sturtivant wrote: struct Test { int i; alias i this; } [...] The assignment is fine, but the call is rejected by dmd. Test t = 1; is rejected too because alias this is not

Re: [unsigned] No, you can't address full address space in D

On Saturday, 20 February 2016 at 17:04:11 UTC, Kagamin wrote: It doesn't even compile: http://dpaste.dzfl.pl/ec0f5183e42e This looks like it's a limit purely on the interface for allocating arrays from the GC. i.e, ubyte* ptr; ubyte arr = ptr[0 .. size_t.max]; compiles just fine

Re: [OT] Some neat ideas from the Kotlin language

On Saturday, 20 February 2016 at 09:40:40 UTC, Tobias Müller wrote: Yuxuan Shui wrote: [...] In Rust that would be: let var : Option = ...; if let Some(var) = var { // You can use var here } It works for every enum (= tagged union), not just Option Swift

Re: std.allocator issues

On Saturday, 20 February 2016 at 02:21:00 UTC, Steven Schveighoffer wrote: I'm trying to use the std.experimental.allocator API more in my new io library, and I'm having a few stumbling points: 1. GCAllocator only allocates void, which is marked as containing pointers. This is no good for a

Re: Poor memory allocation performance with a lot of threads on 36 core machine

On Friday, 19 February 2016 at 08:29:00 UTC, Jonathan M Davis wrote: but the fact that we're a system language that allows you ultimately to do most anything really limits what we can do in comparison to a language sitting in VM. - Jonathan M Davis some small language changes could greatly

Re: Official compiler

On Thursday, 18 February 2016 at 17:52:10 UTC, Kai Nacke wrote: I really like the compiler diversity. What I miss (hint!) is a program to verify the compiler/backend correctness. Just generate a random D program, compile with all 3 compilers and compare the output. IMHO we could find a lot of

Re: Official compiler

On Thursday, 18 February 2016 at 11:41:26 UTC, Kai Nacke wrote: On Thursday, 18 February 2016 at 10:45:54 UTC, Márcio Martins wrote: I suppose it's a lot easier to address the compilation speed issue in LDC/GDC, than to improve and maintain DMD's backend to the expected levels, right? LLVM

Re: Official compiler

On Thursday, 18 February 2016 at 06:57:01 UTC, Kai Nacke wrote: On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins wrote: [...] Hi, even if DMD is the official reference compiler, the download page http://dlang.org/download.html already mentions "strong optimization" as pro of

Re: Official compiler

On Thursday, 18 February 2016 at 02:29:52 UTC, Márcio Martins wrote: On Thursday, 18 February 2016 at 00:06:10 UTC, Xinok wrote: On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins wrote: I was reading the other thread "Speed kills" and was wondering if there is any practical reason

Re: Official compiler

On Wednesday, 17 February 2016 at 22:57:20 UTC, Márcio Martins wrote: I was reading the other thread "Speed kills" and was wondering if there is any practical reason why DMD is the official compiler? [...] Developer politics, I believe. I'm curious where Andrei stands on this issue, IIRC he

Re: Head Const

On Tuesday, 16 February 2016 at 10:31:05 UTC, Guillaume Piolat wrote: On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright wrote: 2. supports single assignment style of programming, even if the data is otherwise mutable Like 'final'? We did get rid of that... Maybe we should

Re: Head Const

On Tuesday, 16 February 2016 at 18:06:05 UTC, karabuta wrote: Hahaha. Well, I think it is already happening. Like the reincarnation of C to C++ story. The focus on interfacing D with C++ lately has been very disconcerting, especially considering features from TDPL are still unfinished

Re: Head Const

On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright wrote: On 2/15/2016 4:15 PM, Daniel Murphy wrote: 1. make it easy to interface to C++ code that uses const, as currently it is not very practical to do so, you have to resort to pragma(mangle) I'd much rather improve pragma(mangle)

Re: @nogc for structs, blocks or modules?

On Tuesday, 16 February 2016 at 03:41:12 UTC, Era Scarecrow wrote: On Tuesday, 16 February 2016 at 03:13:48 UTC, maik klein wrote: I just realized that I can't even use @nogc because pretty much nothing in phobos uses @nogc Or it hasn't been tagged @nogc or based on templates they can't be

Re: Speed kills

On Monday, 15 February 2016 at 13:51:38 UTC, ixid wrote: Every time there is a D thread on reddit it feels like the new user is expecting mind-blowing speed from D. [...] if you want better codegen, don't use dmd. use ldc, it's usualy only a version-ish behind dmd.

Re: D's equivalent to C++'s std::move?

On Saturday, 13 February 2016 at 19:25:37 UTC, Ola Fosheim Grøstad wrote: I'm not sure what you mean by "has move semantics" here. It does not have C++'s move semantics, no, but I would say D has its own move semantics. It has a move() function that transfers raw state between objects, and D

Re: D's equivalent to C++'s std::move?

On Saturday, 13 February 2016 at 20:24:12 UTC, Ola Fosheim Grøstad wrote: On Saturday, 13 February 2016 at 20:11:45 UTC, rsw0x wrote: D "guarantees" NRVO which is what enables its move semantics, C++ did/does not. Quotes because IIRC(?) it used to be part of the spec and it isn't anymore, I

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 22:16:02 UTC, rsw0x wrote: On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote: [...] There's no need. I'll do the implementation with the prefix, and if you do it with a

Re: DigitalWhip

On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: Dear Community, I've prepared a valentine for you;) It's a project I've been working for the last few months in my free time. DigitalWhip is a performance benchmark of statically typed programming languages that compile to

Re: An important pull request: accessing shared affix for immutable data

On Saturday, 13 February 2016 at 21:10:50 UTC, Andrei Alexandrescu wrote: On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote: 2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d >:

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: On 2/12/16 9:37 AM, Matt Elkins wrote: [...] Pass by reference and pass by value means different treatment inside the function itself, so it can't differ from call to call. It could potentially differ based on the type

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: but I'm unaware of such an optimization, and it definitely isn't triggered specifically by 'in'. 'in' is literally replaced with 'scope const' when it is a storage class. -Steve I'd imagine GCC or LLVM may be able to

Re: Things that keep D from evolving?

On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote: On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote: On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer wrote: On 2/12/16 9:37 AM, Matt Elkins wrote: [...] Pass by reference and pass by value means different

Re: Things that keep D from evolving?

On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to

Re: Github woes

On Sunday, 7 February 2016 at 10:48:49 UTC, Joakim wrote: On Sunday, 7 February 2016 at 10:27:02 UTC, Rikki Cattermole wrote: On 07/02/16 11:22 PM, Wobbles wrote: [...] The only thing that we have hosted on Github is code. So excluding integrations, we could move over to Bitbucket without

Re: is increment on shared ulong atomic operation?

On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson wrote: If I define a shared ulong variable, is increment an atomic operation? E.g. shared ulong t; ... t++; It seems as if it ought to be, but it could be split into read, increment, store. I started off defining a shared struct,

Re: is increment on shared ulong atomic operation?

On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote: On Sunday, 7 February 2016 at 19:43:23 UTC, rsw0x wrote: On Sunday, 7 February 2016 at 19:39:27 UTC, rsw0x wrote: On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson wrote: [...]

Re: is increment on shared ulong atomic operation?

On Sunday, 7 February 2016 at 19:39:27 UTC, rsw0x wrote: On Sunday, 7 February 2016 at 19:27:19 UTC, Charles Hixson wrote: If I define a shared ulong variable, is increment an atomic operation? E.g. shared ulong t; ... t++; It seems as if it ought to be, but it could be split into read,

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote: On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote: Can't be done with the root class because classes never trigger RAII outside of (deprecated) scope

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote: Can't be done with the root class because classes never trigger RAII outside of (deprecated) scope allocations. Not sure what you mean. The class instance

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 17:36:28 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote: On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: Nothing prevents you from creating your own reference counting mechanism. A

Bug or intended?

I was playing around with alias templates and came across this, I reduced it to: --- struct A(alias C c){ auto foo(){ return c.i; } } struct B{ C c; A!c a; } struct C{ int i; } --- It gives me a "need 'this' for 'i' of type 'int'" error.

Re: Things that keep D from evolving?

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote: On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote: On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote: What makes it impossible to have ref counted classes? Nothing. Then why do we need DIP74

Re: D's equivalent to C++'s std::move?

On Thursday, 4 February 2016 at 02:33:06 UTC, Andrei Alexandrescu wrote: On 02/03/2016 09:01 PM, Matt Elkins wrote: [...] Got it, thanks. That's a bug in the implementation, no two ways about it. No copy should occur there, neither theoretically nor practically. Please report it to bugzilla

Re: D's equivalent to C++'s std::move?

On Thursday, 4 February 2016 at 03:45:57 UTC, maik klein wrote: On Thursday, 4 February 2016 at 01:26:55 UTC, Andrei Alexandrescu wrote: [...] I am in a similar boat as Matt Elkins. The problem is not D's move semantics, but that Phobos does not support them at all. I have already several

Re: D's equivalent to C++'s std::move?

On Thursday, 4 February 2016 at 03:57:18 UTC, maik klein wrote: On Thursday, 4 February 2016 at 03:52:23 UTC, rsw0x wrote: On Thursday, 4 February 2016 at 03:45:57 UTC, maik klein wrote: [...] Those are intended not to be copied, they must be explicitly moved with std.algorithm's move I

Re: TIOBE February 2016.... 15 ?!

On Wednesday, 3 February 2016 at 07:06:47 UTC, cym13 wrote: It's all true, D rose up 6 positions: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html I don't quite know what the leading factor for that change was but it sure will be great for its image. Doesn't matter if Tiobe

Re: TIOBE February 2016.... 15 ?!

On Wednesday, 3 February 2016 at 19:28:29 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 3 February 2016 at 19:16:00 UTC, Bubbasaur wrote: I take the TIOBE as good PR, because it always appearing on Reddit and people talk about for good or worst. Whenever D is making a marketing push you get

asm.dlang.org has been down for a while

Not sure if this is supposed to be reported on bugzilla or...?

Re: C++17

On Wednesday, 27 January 2016 at 22:18:49 UTC, deadalnix wrote: On Wednesday, 27 January 2016 at 20:51:43 UTC, rsw0x wrote: On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote: On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote: The response from the D community seems to be

Re: C++17

On Wednesday, 27 January 2016 at 15:37:39 UTC, Jack Stouffer wrote: On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote: toy language What is with everyone using inane hyperbole in this thread? Is everyone trying to one up each other? D is a toy language? Really? Tell that to

Re: C++17

On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote: And ironically, in this very thread, a C++ programmer has called D a toy language. C++ programmer No. I've been using D since 2012 and have ported two large personal academic codebases to it. Ignoring the issues D has or

Re: C++17

On Wednesday, 27 January 2016 at 19:21:11 UTC, Abdulhaq wrote: On Wednesday, 27 January 2016 at 18:09:50 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 27 January 2016 at 15:14:07 UTC, bachmeier wrote: And ironically, in this very thread, a C++ programmer has called D a toy language. D is

Re: C++17

On Wednesday, 27 January 2016 at 20:31:33 UTC, deadalnix wrote: On Wednesday, 27 January 2016 at 09:00:17 UTC, rsw0x wrote: The response from the D community seems to be an overwhelming "It's fine as is" when it's obviously not. Which is making me question sinking more time into D if there

Re: C++17

On Wednesday, 27 January 2016 at 08:56:09 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 27 January 2016 at 08:08:30 UTC, Tobias Müller wrote: H. S. Teoh via Digitalmars-d wrote: [long rant] If you want to attract new programmers you should stop constantly

Re: C++17

On Wednesday, 27 January 2016 at 08:48:20 UTC, Mathias Lang wrote: 2016-01-27 8:10 GMT+01:00 rsw0x via Digitalmars-d < digitalmars-d@puremagic.com>: [...] For delegate you can use `scope delegate`, which is stack-allocated. Using a sink-based approach like `toString` that specific

Re: C++17

On Wednesday, 27 January 2016 at 05:32:04 UTC, Chris Wright wrote: On Tue, 26 Jan 2016 21:15:07 +, rsw0x wrote: On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote: On Tue, 26 Jan 2016 19:04:33 +, rsw0x wrote: GC in D is a pipedream, if it wasn't, why is it still so

Re: C++17

On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote: On Tuesday, 26 January 2016 at 15:59:37 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 15:51:22 UTC, deadalnix wrote: On Tuesday, 26 January 2016 at 10:39:03 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January

Re: C++17

On Tuesday, 26 January 2016 at 19:02:54 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 18:57:45 UTC, deadalnix wrote: I don't think it is desirable. I do think we should focus on having GC.malloc/GC.free have the same level of perfs than malloc/free, which is very doable.

Re: C++17

On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote: On the other hand, D's type system can be leveraged to reduce lock contention on the GC (and not lock at all on thread local allocs). There's no such thing in D. shared int* i = new int(5); int* l = new int(5); these call the

Re: C++17

On Tuesday, 26 January 2016 at 20:43:06 UTC, Chris Wright wrote: On Tue, 26 Jan 2016 20:22:19 +, rsw0x wrote: On Tuesday, 26 January 2016 at 20:05:16 UTC, deadalnix wrote: On the other hand, D's type system can be leveraged to reduce lock contention on the GC (and not lock at all on

Re: C++17

On Tuesday, 26 January 2016 at 20:40:50 UTC, Chris Wright wrote: On Tue, 26 Jan 2016 19:04:33 +, rsw0x wrote: GC in D is a pipedream, if it wasn't, why is it still so horrible? Everyone keeps dancing around the fact that if the GC wasn't horrible, nobody would work around it. Rather, if

Re: C++17

On Tuesday, 26 January 2016 at 21:52:32 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 January 2016 at 21:49:16 UTC, Mathias Lang wrote: 2016-01-26 22:15 GMT+01:00 rsw0x via Digitalmars-d < digitalmars-d@puremagic.com>: In any case where you attempt to write code in D that is

Re: C++17

On Tuesday, 26 January 2016 at 21:01:53 UTC, bachmeier wrote: "With C++xx, there's little benefit to switching" is a very common sentiment among current C++ programmers. And it's probably true. On the other hand, with a few exceptions, it's hard to see someone choosing to learn C++ rather than

Re: Vision 2016 H1

On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu wrote: In case you missed it from the announce forum: http://wiki.dlang.org/Vision/2016H1 -- Andrei Maybe we should finally decide what color to paint the bikeshed?

Re: Vision 2016 H1

On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu wrote: In case you missed it from the announce forum: http://wiki.dlang.org/Vision/2016H1 -- Andrei We are still shorthanded with all aspects of D development: top leadership, I'd be interested in seeing someone with good

Re: Pre-alpha D language online tour

On Monday, 25 January 2016 at 21:12:14 UTC, André wrote: [...] might be worth noting that Rust uses playpen for sandboxing their online compiler https://github.com/thestinger/playpen

Re: Pre-alpha D language online tour

On Monday, 25 January 2016 at 18:17:09 UTC, André wrote: This tour doesn't allow compiling online because the current implementation would just make it too easy to hijack the server :-) Compiling and running online can be activated when compiling locally though. My goal would be to integrate

Re: Downtime of gdc ftp, bugzilla, site, et. al.

On Sunday, 24 January 2016 at 17:18:24 UTC, Iain Buclaw wrote: GDC explorer is in a partial state (currently getting ARM, AArch64, PPC, and PPC64 disassemblers working). Where can I find GDC explorer?

Re: [dlang.org] Let's talk about the logo

On Saturday, 23 January 2016 at 15:41:43 UTC, ronaldmc wrote: On Saturday, 23 January 2016 at 01:23:20 UTC, H. S. Teoh wrote: [...] Because maybe you don't read too much (outside programming), you can easily find the term being used on open source. i.e:

Re: [dlang.org] Let's talk about the logo

On Friday, 22 January 2016 at 20:28:57 UTC, anonymous wrote: On 22.01.2016 20:53, ronaldmc wrote: I don't want to start a war, but this isn't community? I mean aren't we trying to make things better, because the way you said it seems like a dictatorship. It's dictatorship insofar as Walter

Re: D's metaprogramming could be flawed

On Friday, 22 January 2016 at 12:57:54 UTC, maik klein wrote: ... You're looking for AliasSeq in std.meta, it's a tup—er, finite ordered list of types :)

Re: D's metaprogramming could be flawed

On Friday, 22 January 2016 at 13:28:00 UTC, maik klein wrote: On Friday, 22 January 2016 at 13:21:11 UTC, rsw0x wrote: On Friday, 22 January 2016 at 12:57:54 UTC, maik klein wrote: ... You're looking for AliasSeq in std.meta, it's a tup—er, finite ordered list of types :) I am already

Re: Why do some attributes start with '@' while others done't?

On Friday, 22 January 2016 at 15:34:18 UTC, Wyatt wrote: On Friday, 22 January 2016 at 08:23:48 UTC, Ola Fosheim Grøstad wrote: [...] "Contemporary". ;) Aside from Swift's optional semicolons, they're really not all that different. [...] Like Swift, C#, Javascript, Go, Haxe, Rust, Dart,

Re: Why do some attributes start with '@' while others done't?

On Thursday, 21 January 2016 at 23:05:51 UTC, Dibyendu Majumdar wrote: I am puzzled as to why there is @nogc on the one hand and simply nothrow on the other? Why are some attributes prefixed with '@' while others aren't? Regards "breakage" that could be fixed in a few minutes with grep

Re: [dlang.org] Let's talk about the logo

On Thursday, 21 January 2016 at 23:46:26 UTC, anonymous wrote: ... bottom two are the best. mixing matte and glossy is just *ugly*

Re: Why do some attributes start with '@' while others done't?

On Friday, 22 January 2016 at 04:30:33 UTC, tsbockman wrote: On Friday, 22 January 2016 at 02:13:56 UTC, Ola Fosheim Grøstad wrote: [...] I don't necessarily disagree with your overall point, but I think the question of whether a few attributes have an @ attached to them or not ranks pretty

Re: D Article: Memory Safety

On Wednesday, 20 January 2016 at 14:04:53 UTC, Jakob Ovrum wrote: The article aims to explain how to use @safe, @system and importantly, @trusted, including all the hairy details of templates. https://jakobovrum.github.io/d/2016/01/20/memory-safety.html Any and all feedback appreciated. my

Re: extern(C++, ns)

On Tuesday, 19 January 2016 at 13:56:54 UTC, Manu wrote: ... Sorry for the noise, but this is a very long thread. Can someone just summarize how C++ namespaces work when interfacing with D? I assumed they just behaved exactly like D modules do, is this wrong?

Re: local import hijacking

On Monday, 18 January 2016 at 13:26:24 UTC, Jack Stouffer wrote: On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote: I think it's time to dedicate a whole release to work on imports. Please do. D is damn lucky that the main problem people think it has is the GC while it's

Re: Premake officially gains D support

On Monday, 18 January 2016 at 13:31:09 UTC, Russel Winder wrote: On Mon, 2016-01-18 at 11:14 +, Dragos Carp via Digitalmars-d wrote: […] cmake-d is still active, just not so much used. I'll try to address any issue that arise. Splendid. I'll see if it is possible to integrate this with

Re: local import hijacking

On Thursday, 14 January 2016 at 22:33:51 UTC, H. S. Teoh wrote: On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: On 01/14/2016 02:10 PM, Joakim wrote: >Wow, can't believe his PR has been sitting unreviewed for 5 >months: >

Re: On Dub

On Sunday, 17 January 2016 at 12:32:47 UTC, Russel Winder wrote: On Sun, 2016-01-17 at 12:17 +, Guillaume Piolat via Digitalmars-d wrote: On Sunday, 17 January 2016 at 11:21:41 UTC, Russel Winder wrote: > Cargo puts compilation products into the using project tree > and not the ~/.cargo

Re: On Dub

On Sunday, 17 January 2016 at 11:21:41 UTC, Russel Winder wrote: Dub has a "run" capability, but apparently no "install" one. Also it appears to leave compilation products inside the ~/.dub directory. Go puts compiled executables into $GOPATH/bin or $GOBIN and packages in $GOPATH/pkg which

Re: On Dub

On Sunday, 17 January 2016 at 15:34:13 UTC, Russel Winder wrote: On Sun, 2016-01-17 at 12:39 +, rsw0x via Digitalmars-d wrote: […] It wouldn't be a very big change to just adhere to $DUBPPATH if it exists, which seems to be your major gripe about Go vs Dub. My gripe is that Dub

Re: Functions that return type

On Saturday, 16 January 2016 at 21:22:15 UTC, data pulverizer wrote: Is it possible to create a function that returns Type like typeof() does? Something such as: Type returnInt(){ return int; } Functions return values, not types. You would use a template to "return" a type. More to

Re: function argument accepting function or delegate?

On Sunday, 17 January 2016 at 06:27:41 UTC, Jon D wrote: My underlying question is how to compose functions taking functions as arguments, while allowing the caller the flexibility to pass either a function or delegate. [...] Templates are an easy way. --- auto call(F, Args...)(F fun, auto

Re: DIP83

On Friday, 15 January 2016 at 11:58:19 UTC, Márcio Martins wrote: On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote: [...] True that. I think it's great to keep evolving the language and making it better, on the other hand, if D is to get serious adoption, then everything,

Re: DIP83

On Friday, 15 January 2016 at 13:20:18 UTC, deadalnix wrote: On Friday, 15 January 2016 at 11:11:41 UTC, Tofu Ninja wrote: On Thursday, 14 January 2016 at 14:28:05 UTC, deadalnix wrote: We don't have line number in stack traces Huh? We dont have line numbers in stack traces? I have line

Structs intended to run destructor immediately if not assigned to a variable?

Returning a struct with a destructor and not binding it to a variable appears to make the destructor run immediately instead of at the end of the scope. Is this intended? example: http://dpaste.dzfl.pl/dd285200ba2b

Re: LDC 0.17.0-beta1 has been released!

On Thursday, 14 January 2016 at 20:57:02 UTC, Kai Nacke wrote: On Thursday, 14 January 2016 at 20:37:13 UTC, rsw0x wrote: Congratulations on Win64 support — is this the first LDC version with it? No. Since 0.16.0 we regard the Win64 support as production-ready. Regards, Kai I must have

Re: LDC 0.17.0-beta1 has been released!

On Thursday, 14 January 2016 at 20:33:30 UTC, Kai Nacke wrote: Hi everyone, LDC 0.17.0-beta1, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.7. Don't miss to check if your preferred system is

Re: std.experimental.yesnogc

On Thursday, 14 January 2016 at 00:35:53 UTC, Andrei Alexandrescu wrote: Hey folks, I want to push things forward with artifacts dedicated to avoiding the GC, and of course my main worry is finding the right name. An obvious choice is std.experimental.nogc but we know from Marketing 101 that

CAS and atomicOp!"" memory ordering?

Why is there no way to specify the desired memory order with these? What memory order am I supposed to assume? The documentation is sparse.

If Java Were Designed Today: The Synchronizable Interface

http://blog.jooq.org/2016/01/12/if-java-were-designed-today-the-synchronizable-interface/ D's synchronized classes and statements are (AFAIK) very similar to Java's so I thought this might spark an interesting discussion.

Re: "Good PR" mechanical check

On Tuesday, 12 January 2016 at 18:25:48 UTC, tsbockman wrote: On Tuesday, 12 January 2016 at 13:34:25 UTC, Andrei Alexandrescu wrote: [...] I realize that dfmt may need some upgrades first, but isn't it about time to just suck it up and dfmt the whole of phobos and druntime? It will mess

Re: issue porting C++/glm/openGL to D/gl3n/openGL

On Tuesday, 12 January 2016 at 01:00:30 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker.

Re: flag -ignore_nogc to allow breaking nogc rules during debugging [analog to debug for pure]

On Sunday, 10 January 2016 at 09:17:20 UTC, Timothee Cour wrote: this would make error handling trivial and solve issues such as this: FORUM:formatted assert error messages inside nogc functions http://forum.dlang.org/thread/CANri+EyNyrhMWGCSqZHx_vXDJFSrwhOrV=j2katz6t9-upt...@mail.gmail.com

Re: Anyone using glad?

On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote: Seems like it is a very nice way to get into openGL from D. http://glad.dav1d.de/ I generated the bindings for all the latest versions of the various specifications. Does anyone have any tutorials that use this library

  1   2   3   4   5   >