The progress of D since 2013

Hi! Good to see D is progressing! I was active forum and bugzilla participant in 2011-2013. Since then I have not touched D. What is the progress of D (2014-2017) in following dimensions: 1) Support of linking in win64? AFAIK Walter introduced win64 support in circa 2012 which was the big

Re: char[] == null

On Thursday, 19 November 2015 at 15:36:44 UTC, Steven Schveighoffer wrote: On 11/19/15 3:30 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Wednesday, November 18, 2015 22:15:19 anonymous via Digitalmars-d-learn wrote: On 18.11.2015 22:02, rsw0x wrote: slices aren't arrays

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 21:22:04 UTC, ixid wrote: On Wednesday, 4 November 2015 at 19:09:42 UTC, Maxim Fomin wrote: On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with

Re: Preventing implicit conversion

On Wednesday, 4 November 2015 at 14:27:49 UTC, ixid wrote: Is there an elegant way of avoiding implicit conversion to int when you're using shorter types? Only with library solution. Implicit conversions are built into language.

Re: Overloading an imported function

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma wrote: import std.math; real round(real val, int prec) { real pow = 10 ^^ prec; return round(val * pow) / pow; } Trying to compile this I get: foo.d(5): Error: function foo.round (real val, int prec) is not callable

Re: Array of subclasses

On Thursday, 22 October 2015 at 13:29:06 UTC, DarkRiDDeR wrote: I don't need the base class data. How to create a array of subclasses objects with the derived data members? The language is implemented in this way. You have already have the answer: writeln(Core.users.name) Out: USERS

Re: Array of subclasses

On Thursday, 22 October 2015 at 11:02:05 UTC, DarkRiDDeR wrote: This variant works strangely. Example: abstract class Addon { public string name = "0"; } class Users: Addon { override { public string name = "USERS"; } } static final class Core {

Re: Implicit conversion rules

On Wednesday, 21 October 2015 at 19:49:35 UTC, Ali Çehreli wrote: On 10/21/2015 12:37 PM, Sigg wrote: > cause at least few more "fun" side effects. One of those side effects would be function calls binding silently to another overload: void foo(bool){/* ... */} void foo(int) {/* ... */}

Re: Implicit conversion rules

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote: Am Wed, 21 Oct 2015 12:49:35 -0700 schrieb Ali Çehreli : On 10/21/2015 12:37 PM, Sigg wrote: > cause at least few more "fun" side effects. One of those side effects would be function calls binding

Re: Moving back to .NET

On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc wrote: On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote: OK, the frustration is understandable. D is good enough to impress in short-run but has problems damaging itself in the long run. This leads to impression ->

Re: Moving back to .NET

On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: Sure, but in many cases D allows you to work around decisions you don't like. Plus, you can actively contribute, make suggestions and prove your case. The length of

Re: Moving back to .NET

On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote: On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin wrote: On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions

Re: Moving back to .NET

On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote: to be confined by committee decisions etc., D has committee (Walter & Andrei). Some of their decisions frustrate D users too.

Re: Moving back to .NET

On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote: My experiences with D recently have not been fun. ... My main concern with .NET is portability and performance. I am going to give in to the portability and just assume Mono is good enough. Performance wise, I'd prefer D, but .NET is

Re: D for Game Development

On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote: After leaving C++ behind for a few years to work in some higher-level languages for job-related coding, I was excited when I stumbled upon D ... This is a typical path ... I spent several weeks tearing through the language reference

Re: how come is this legal? 'void fun(int){ }' ?

On Sunday, 14 June 2015 at 01:20:39 UTC, Timothee Cour wrote: I understand this is legal for declaration wo definition (void fun(int);) but why allow this: void test(int){} ? Actually it is void test(int _param_0) { } You can test by compiling void test(int) { _param_0 = 0; } Nameless

Re: Thoughts about the ideal programming language

On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote: Hi, I think that many will find something interesting in this article: - https://translate.google.ru/translate?hl=rusl=rutl=enu=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F - Sorry translated using google translate. Can

Re: Cannot Qualify Variadic Functions with Lazy Arguments as nothrow

On Thursday, 14 May 2015 at 09:53:20 UTC, Per Nordlöw wrote: At https://github.com/nordlow/justd/blob/master/algorithm_ex.d#L43 I've implemented a function either() with behaviour similar to the `or` function/operator in dynamic languages such as Python and Lisp. I'm almost satisified with

Re: D casually mentioned and dismissed + a suggestion

On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote: You are making a cool project and we'd like to contribute to it, but we don't know and neither feel like studying this silly D. This is indeed a problem for many newly created languages. Scala has somewhat managed to create its own

Re: UDAs and no complaints about need 'this'

On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote: struct BigLongStructName { int evenLongerMemberName; } struct QN{} unittest { BigLongStructName bigLongStructName; @(bigLongStructName.evenLongerMemberName) QN quickName;

Re: size_t for length on x64 will make app slower than on x86?

On Sunday, 16 November 2014 at 13:39:24 UTC, FrankLike wrote: Many old projects need move from x86 to x64,but the 'length' type is size_t,it will change on x64,so a lot of work must to do.but I find some info which is help for d: http://www.dotnetperls.com/array-length. it means: test length

Re: DMD v2.066.0-rc1

On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote: DMD v2.066.0-rc1 binaries are available for testing: http://wiki.dlang.org/Beta_Testing What about changelog? http://dlang.org/changelog.html In past it was pretty nicely made, but now it lists only 2 changes (unlike

errno_c.obj in druntime

Currently I am building dmd on win64. For some reason some phobos code references getErrno() function in errno_c.obj and that object file is not included into final binary (linker issues symbol absence error - by the way I don't remember it was needed on linux). It can be avoided by adding

Re: Can't modify this

On Saturday, 28 June 2014 at 20:40:21 UTC, Ary Borenszweig wrote: This doesn't work: class Foo { this() { this = new Foo; } } Error: Cannot modify 'this' However you can do this: class Foo { this() { auto p = this; *p = new Foo(); } } It even changes the value of this!

Re: Constant relationships between non-constant objects

On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote: So again, I believe, if D wants to play any role in major OO software design and development, it will need to step up its game. Especially in view of C++11 having addressed a number of the issues in C++ that I would have

Re: Unnamed parameter with default value

On Tuesday, 17 June 2014 at 15:15:44 UTC, Luís Marques wrote: Is there any particular reason why this is accepted? (I introduced it by mistake): void foo(int = 3) {} I guess it could be useful to ensure binary compatibility when you expect to add the parameter later? Actually there is

Re: Tail pad optimization, cache friendlyness and C++ interrop

On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote: On 6/11/2014 4:34 AM, Timon Gehr wrote: Not memory safe implies (is supposed to imply) not @safe but not @safe does not imply not memory safe. @safe in D == memory safe. Why? I found dozens of cases when @safe is broken, let

Re: Why are breakpoints caught by the runtime?

On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Schütz wrote: On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote: void main() { asm { int 3; } } object.Error: Breakpoint 0x00402013 in _Dmain at bptest.d(6) 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern

Re: Why are breakpoints caught by the runtime?

On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote: void main() { asm { int 3; } } object.Error: Breakpoint 0x00402013 in _Dmain at bptest.d(6) 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1()

Re: Null pointer dereferencing in D

On Saturday, 14 June 2014 at 12:33:28 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote: Huh? Types with `@disable this()` still have an `init` value. All it does is disallow instantiating the type without specifying an initializer (e.g. a struct literal, a value

Re: Null pointer dereferencing in D

On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote: Which is effectively a type system hole with @disable this : struct A { @disable this(); } auto a = A.init; Why this is a type hole if initializer is explicitly provided?

Re: Null pointer dereferencing in D

On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote: On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote: On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote: Which is effectively a type system hole with @disable this : struct A { @disable this(); } auto a = A.init;

Re: Null pointer dereferencing in D

On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote: On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote: The case which you described is a not a type safety problem. If a struct type has a non-trivial invariant(), .init allows an object to exist that violates it

Re: Null pointer dereferencing in D

On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote: On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote: The case which you described is a not a type safety problem. If a struct type has a non-trivial invariant(), .init allows an object to exist that violates it