Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 2015-08-20 23:06, Walter Bright wrote: As I recall, I posted a survey of syntax from maybe a dozen languages, and the community picked the one they liked the best. Yeah, I remember that for the lambda syntax. Not sure about when the delegate syntax was introduced. That was present when I s

Re: Object.factory() and exe file size bloat

On 2015-08-21 07:06, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat:

Re: Object.factory() and exe file size bloat

On Friday, 21 August 2015 at 05:24:52 UTC, BBasile wrote: On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every clas

Re: Object.factory() and exe file size bloat

On 8/21/2015 5:06 PM, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat:

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On 8/21/2015 5:43 PM, Walter Bright wrote: On 8/20/2015 7:50 PM, Rikki Cattermole wrote: And that we are doing it properly, first time. Props to you Walter for being the no-man! We've still made many mistakes. But C++ is a lot more trapped by the past than D is - such as the random size of 'i

Re: Object.factory() and exe file size bloat

On 8/20/2015 11:00 PM, Mike wrote: Ideally it would be nice to only pull in those ModuleInfo instances that are actually needed in the program, and by association, only pull in those TypeInfo instances needed by the ModuleInfo. If no ModuleInfo is used, and the associated TypeInfo is also not us

Re: Object.factory() and exe file size bloat

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it.

Re: Object.factory() and exe file size bloat

On Friday, 21 August 2015 at 05:35:21 UTC, Walter Bright wrote: On 8/20/2015 10:24 PM, BBasile wrote: Other alternatives would be a pragma or an attribute to disable TypeInfo generation. Interestingly, my idea would not disable TypeInfo generation. Instead, the TypeInfo would be generated in

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On 8/20/2015 7:50 PM, Rikki Cattermole wrote: And that we are doing it properly, first time. Props to you Walter for being the no-man! We've still made many mistakes. But C++ is a lot more trapped by the past than D is - such as the random size of 'int', the macro preprocessor, syntax, useles

Re: Object.factory() and exe file size bloat

On 8/20/2015 10:24 PM, BBasile wrote: Other alternatives would be a pragma or an attribute to disable TypeInfo generation. Interestingly, my idea would not disable TypeInfo generation. Instead, the TypeInfo would be generated into a COMDAT section. Then, only if it is referenced is it linked

Re: Object.factory() and exe file size bloat

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it:

Re: Object.factory() and exe file size bloat

On Fri, Aug 21, 2015 at 05:15:00AM +, deadalnix via Digitalmars-d wrote: > On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: > >This function: > > > > http://dlang.org/phobos/object.html#.Object.factory > > > >enables a program to instantiate any class defined in the program. To

Re: Object.factory() and exe file size bloat

On Friday, 21 August 2015 at 05:06:47 UTC, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it.

Re: Object.factory() and exe file size bloat

On 21-Aug-2015 08:06, Walter Bright wrote: This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat:

Object.factory() and exe file size bloat

This function: http://dlang.org/phobos/object.html#.Object.factory enables a program to instantiate any class defined in the program. To make it work, though, every class in the program has to have a TypeInfo generated for it. This leads to bloat: https://issues.dlang.org/show_bug.cgi?id

Re: dpaste web site

On Thursday, 20 August 2015 at 20:28:48 UTC, Steven Schveighoffer wrote: dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 20:43:39 UTC, Steven Schveighoffer wrote: This makes me think you misunderstand what I am doing. If you care about whether an array is empty, you check whether its length is 0 or you call empty (which checks whether the length is 0). If you care about whether th

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On 8/21/2015 11:58 AM, Walter Bright wrote: On 8/20/2015 3:35 PM, H. S. Teoh via Digitalmars-d wrote: I posted in another thread a while back a list of D features that C++ is rushing to incorporate. The problem is that they're incorporating them poorly and ugly. [...] Is it really a *problem

Re: dmd codegen improvements

On Friday, 21 August 2015 at 01:20:27 UTC, jmh530 wrote: On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote: The gdc version, by contrast, inlines *everything*, This could be why I've observed performance differentials in dmd for doing some manual for loops rather than using the stu

Re: dmd codegen improvements

On 8/20/2015 6:06 PM, H. S. Teoh via Digitalmars-d wrote: https://issues.dlang.org/show_bug.cgi?id=14943 Thanks!

Re: 2.068.0 regression?

On 08/21/2015 03:51 AM, Timon Gehr wrote: Even if an import is unused, if there is at least one lookup of some identifier from any different module, it will have to be analyzed. (But not /transitively/. I think this is where the gains of lazy imports come from.)

Re: 2.068.0 regression?

On 08/20/2015 11:00 PM, deadalnix wrote: On Thursday, 20 August 2015 at 20:27:58 UTC, Timon Gehr wrote: - We'd like to be able to lazy import as much as possible. If import can hijack, I assume what you mean is if it can cause a compiler error due to ambiguity in cross-scope overloading.

Re: dmd codegen improvements

On Fri, Aug 21, 2015 at 01:20:25AM +, jmh530 via Digitalmars-d wrote: > On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote: > > > >The gdc version, by contrast, inlines *everything*, > > This could be why I've observed performance differentials in dmd for > doing some manual for loops

Re: dmd codegen improvements

On Friday, 21 August 2015 at 00:00:09 UTC, H. S. Teoh wrote: The gdc version, by contrast, inlines *everything*, This could be why I've observed performance differentials in dmd for doing some manual for loops rather than using the stuff in std.algorithms.

Re: dmd codegen improvements

On Thu, Aug 20, 2015 at 05:30:25PM -0700, Walter Bright via Digitalmars-d wrote: > On 8/20/2015 4:56 PM, H. S. Teoh via Digitalmars-d wrote: > >I didn't include the assembly listings, as it's rather long, but if > >people are interested I'll trim them down to the parts of interest > >and post them

Re: dmd codegen improvements

On 8/20/2015 4:56 PM, H. S. Teoh via Digitalmars-d wrote: I didn't include the assembly listings, as it's rather long, but if people are interested I'll trim them down to the parts of interest and post them in a follow-up post. Thank you. This belongs as an enhancement request in bugzilla, usin

Amazing brand spanking new programming concept: Parameter Paths!

Parameter paths, a thousand words summed up: void foo(p1, p2|p3|p4, p5|p6, |*p7|p8){ ... } Parameter paths provide a very simple way to express multiple parameter paths for a function. It is similar but not the same as operator overloading. Essentially, a symbol such as '|' is used to separa

Re: Matrix API support - start with formats?

On 15 August 2015 at 05:11, Tofu Ninja via Digitalmars-d wrote: > On Friday, 14 August 2015 at 18:51:51 UTC, David Nadlinger wrote: >> >> On Friday, 14 August 2015 at 15:11:39 UTC, ponce wrote: >>> >>> Are sparse matrices a common scenario? >> >> >> Yes. They tend to pop up in virtually all "serio

Re: dmd codegen improvements

On Tue, Aug 18, 2015 at 04:30:26PM -0700, Walter Bright via Digitalmars-d wrote: > On 8/18/2015 4:05 PM, H. S. Teoh via Digitalmars-d wrote: > >Maybe when I get some free time this week, I could look at the > >disassembly of one of my programs again to give some specific > >examples. > > Please do

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On 8/20/2015 3:35 PM, H. S. Teoh via Digitalmars-d wrote: I posted in another thread a while back a list of D features that C++ is rushing to incorporate. The problem is that they're incorporating them poorly and ugly. [...] Is it really a *problem*, though? ;-) Having C++ play catchup with

std.traits: ParameterIdentifierTuple on 'interface' not working ?

Is this behaviour expected ? (dmd2.068, linux 64bit) dmd -oftest test.d (string, uint, bool) tuple("a", "b", "c") (string, uint, bool) tuple("", "", "") (i.e. ParameterIdentifierTuple does not appear to work for interfaces? - what am I doing incorrectly?) test.d: import std.traits; interface

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On Thu, Aug 20, 2015 at 10:34:08PM +, rsw0x via Digitalmars-d wrote: > On Thursday, 20 August 2015 at 22:22:26 UTC, Walter Bright wrote: > >On 8/20/2015 3:07 PM, John Carter wrote: > >>https://twitter.com/yukihiro_matz/status/634386185507311616 > >> > >>Yet another choice D got right "out of th

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On Thursday, 20 August 2015 at 22:22:26 UTC, Walter Bright wrote: On 8/20/2015 3:07 PM, John Carter wrote: https://twitter.com/yukihiro_matz/status/634386185507311616 Yet another choice D got right "out of the box" :-) Even Bjarne is coming around to the "Generic all the time" view... h

Re: Automatically verifying code samples on dlang.org

On Thu, Aug 20, 2015 at 08:51:57AM +0200, Jacob Carlborg via Digitalmars-d wrote: > A post in the learn newsgroup got me thinking. Do we have a way to > automatically verify code samples on dlang.org? I know that for the > Phobos and druntime docs we can use documented unit test blocks but > what

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On 8/20/2015 3:07 PM, John Carter wrote: https://twitter.com/yukihiro_matz/status/634386185507311616 Yet another choice D got right "out of the box" :-) Even Bjarne is coming around to the "Generic all the time" view... https://www.youtube.com/watch?v=xcpSLRpOMJM Pity that concepts looks

Re: Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

On Thursday, 20 August 2015 at 22:07:10 UTC, John Carter wrote: Pity that concepts looks to be a very painful syntax for expressing what D does so clearly. I believe this is the main reason people use D.

Ruby 3.0 to have immutable strings by default / C++ heading towards "generic all the time".

https://twitter.com/yukihiro_matz/status/634386185507311616 Yet another choice D got right "out of the box" :-) Even Bjarne is coming around to the "Generic all the time" view... https://www.youtube.com/watch?v=xcpSLRpOMJM Pity that concepts looks to be a very painful syntax for expressing

Re: Matrix API support - start with formats?

On Thursday, 20 August 2015 at 21:28:10 UTC, jmh530 wrote: https://github.com/clMathLibraries/clBLAS https://github.com/clMathLibraries/clRNG https://github.com/clMathLibraries/clSPARSE https://github.com/clMathLibraries/clFFT They also made some available through https://github.com/flame I p

Re: Matrix API support - start with formats?

On Friday, 14 August 2015 at 20:23:00 UTC, jmh530 wrote: I agree. MKL is expensive. OpenBLAS is supposed have comparable performance, more or less, and it is free. Alternately, ATLAS can be used to build BLAS on many different systems. I would also distinguish between the low level API like

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 8/19/2015 3:09 AM, Chris wrote: #3 Here we go again... I wonder what's the problem with this. I still think it's a very handy shorthand for cumbersome `x = x + 1` or even `x += 1`. And no, it's not confusing, because it is well defined as incrementing the value by 1. In fact, I don't like Pyth

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 8/19/2015 1:47 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= wrote: I see your point, but it isn't so clear cut. When you are doing a high level APIs, like an ORM you might want to enforce having a field on the left and a number on the right and return a query building type. So you can type "db.qu

Re: string <-> null/bool implicit conversion

On 8/20/15 4:45 PM, Timon Gehr wrote: On 08/20/2015 10:43 PM, Steven Schveighoffer wrote: On 8/20/15 4:38 PM, Jonathan M Davis wrote: And why would you want that? The length is meaningless if the pointer is null. It shouldn't even be possible for the length to be anything other than zero if the

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 8/20/2015 7:52 AM, renoX wrote: No IMHO, it's not really the fault of floating point numbers, it's the languages fault: gloating point standard contain the 'signaling NaN', It has nothing to do with signalling nan, it has to do with nan.

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On 8/19/2015 12:40 AM, Jonathan M Davis wrote: D copied it from C#. As I recall, I posted a survey of syntax from maybe a dozen languages, and the community picked the one they liked the best.

Re: 2.068.0 regression?

On Thursday, 20 August 2015 at 20:27:58 UTC, Timon Gehr wrote: - We'd like to be able to lazy import as much as possible. If import can hijack, I assume what you mean is if it can cause a compiler error due to ambiguity in cross-scope overloading. Yes, but eve if it doesn't, one need to

Re: string <-> null/bool implicit conversion

On 08/20/2015 10:43 PM, Steven Schveighoffer wrote: On 8/20/15 4:38 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote: On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr

Re: string <-> null/bool implicit conversion

On 8/20/15 4:38 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote: On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== null a

Re: string <-> null/bool implicit conversion

On 08/20/2015 10:38 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote: On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== nu

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 19:54:22 UTC, Steven Schveighoffer wrote: On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== null and "!= null" should be illegal. If you reall

Re: dpaste web site

On Thursday, 20 August 2015 at 20:28:48 UTC, Steven Schveighoffer wrote: dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at

Re: string <-> null/bool implicit conversion

On 08/20/2015 10:26 PM, David Nadlinger wrote: On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote: Having 2 empty strings evaluate differently is very unintuitive and error-prone, in my opinion. It's even worse: http://dpaste.dzfl.pl/ba3376feca8e The arrays are equal, but their

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote: Having 2 empty strings evaluate differently is very unintuitive and error-prone, in my opinion. It's even worse: http://dpaste.dzfl.pl/ba3376feca8e The arrays are equal, but their Boolean value is not. I don't get how Andrei c

Re: 2.068.0 regression?

On 08/20/2015 10:06 PM, deadalnix wrote: On Thursday, 20 August 2015 at 10:46:18 UTC, Timon Gehr wrote: On 08/20/2015 05:55 AM, Andrei Alexandrescu wrote: We need to fix the implementation. We can't promote imports that hide local symbols. -- Andrei Great! We should probably agree on the pre

dpaste web site

dpaste.dzfl.pl is severely out of date. Who maintains this and can we get it updated? It's going to start hurting us pretty severely if we use it as our go-to site for pasting compiled-and-run d snippets, but it's only at version 2.065. -Steve

Re: string <-> null/bool implicit conversion

On 08/20/2015 09:08 PM, Steven Schveighoffer wrote: On 8/20/15 2:49 PM, Timon Gehr wrote: On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] The main reason why it caused issues is this nice

Re: 2.068.0 regression?

On Thursday, 20 August 2015 at 10:46:18 UTC, Timon Gehr wrote: On 08/20/2015 05:55 AM, Andrei Alexandrescu wrote: We need to fix the implementation. We can't promote imports that hide local symbols. -- Andrei Great! We should probably agree on the precise new semantics first though. The

Re: string <-> null/bool implicit conversion

On 08/20/2015 09:54 PM, Steven Schveighoffer wrote: On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== null and "!= null" should be illegal. If you really want to check for nu

Re: string <-> null/bool implicit conversion

On 08/20/2015 09:08 PM, Steven Schveighoffer wrote: On 8/20/15 2:43 PM, Timon Gehr wrote: On 08/20/2015 07:50 PM, Steven Schveighoffer wrote: Very true. Not much we can do about it. For now, the best thing to do is always compare arrays to null instead of simply if(arr): if(arr != null) Alte

Re: string <-> null/bool implicit conversion

On 8/20/15 3:41 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== null and "!= null" should be illegal. If you really want to check for null, then you need to use "is null" or "!is null", whe

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 17:50:11 UTC, Steven Schveighoffer wrote: if(arr != null) Definitely don't do that. IMHO, "== null and "!= null" should be illegal. If you really want to check for null, then you need to use "is null" or "!is null", whereas if you want to check that an array is

Re: string <-> null/bool implicit conversion

On 8/20/15 3:04 PM, "=?UTF-8?B?Ik3DoXJjaW8=?= Martins\" \"" wrote: On Thursday, 20 August 2015 at 18:42:56 UTC, Márcio Martins wrote: On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer wrote: On 8/20/15 1:50 PM, Steven Schveighoffer wrote: The "truthiness" of an array says it's

Re: string <-> null/bool implicit conversion

On 8/20/15 2:43 PM, Timon Gehr wrote: On 08/20/2015 07:50 PM, Steven Schveighoffer wrote: Very true. Not much we can do about it. For now, the best thing to do is always compare arrays to null instead of simply if(arr): if(arr != null) Alternatively, but a little more ugly, is to check the le

Re: string <-> null/bool implicit conversion

On 8/20/15 2:49 PM, Timon Gehr wrote: On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] The main reason why it caused issues is this nice idiom: if(auto arr = someFunction()) { // use ar

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 18:42:56 UTC, Márcio Martins wrote: On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer wrote: On 8/20/15 1:50 PM, Steven Schveighoffer wrote: The "truthiness" of an array says it's true ONLY if both the pointer and length are 0. Ugh, *false* onl

Re: string <-> null/bool implicit conversion

On 08/20/2015 07:32 PM, Jonathan M Davis wrote: On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote: A compiler change disallowing such use of arrays was done and then reverted. See . I haven't followed things closely enough to give you a g

Re: string <-> null/bool implicit conversion

On 08/20/2015 08:05 PM, H. S. Teoh via Digitalmars-d wrote: On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] The main reason why it caused issues is this nice idiom: if(auto arr = someFunction()) { // use arr } This would HAVE to be split out t

Re: string <-> null/bool implicit conversion

On 08/20/2015 07:50 PM, Steven Schveighoffer wrote: Very true. Not much we can do about it. For now, the best thing to do is always compare arrays to null instead of simply if(arr): if(arr != null) Alternatively, but a little more ugly, is to check the length: if(arr.length) Isn't the best

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 18:04:00 UTC, Steven Schveighoffer wrote: On 8/20/15 1:50 PM, Steven Schveighoffer wrote: The "truthiness" of an array says it's true ONLY if both the pointer and length are 0. Ugh, *false* only if they are both 0. If either are not zero, then it's true. -St

Re: string <-> null/bool implicit conversion

On Thu, Aug 20, 2015 at 01:50:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...] > The main reason why it caused issues is this nice idiom: > > if(auto arr = someFunction()) > { >// use arr > } > > This would HAVE to be split out to two statements, and the arr variable > would b

Re: string <-> null/bool implicit conversion

On 8/20/15 1:50 PM, Steven Schveighoffer wrote: The "truthiness" of an array says it's true ONLY if both the pointer and length are 0. Ugh, *false* only if they are both 0. If either are not zero, then it's true. -Steve

Re: string <-> null/bool implicit conversion

On 8/20/15 12:45 PM, "=?UTF-8?B?Ik3DoXJjaW8=?= Martins\" \"" wrote: Hi! string a = ""; string b; writeln(a ? "a" : "null"); writeln(b ? "b" : "null"); This program outputs: a null What? I suppose this is by design, but are there any plans to deprecate this? The "truthiness" of an array

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 17:01:07 UTC, anonymous wrote: A compiler change disallowing such use of arrays was done and then reverted. See . I haven't followed things closely enough to give you a good summary. Basically, almost everyone wante

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On Thu, Aug 20, 2015 at 04:56:15PM +, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, 20 August 2015 at 16:44:44 UTC, H. S. Teoh wrote: > >On Thu, Aug 20, 2015 at 04:22:20PM +, Jonathan M Davis via > >Digitalmars-d wrote: [...] > >>I really don't mind NaN. It really doesn't cause

Re: string <-> null/bool implicit conversion

On Thursday, 20 August 2015 at 16:45:18 UTC, Márcio Martins wrote: Hi! string a = ""; string b; writeln(a ? "a" : "null"); writeln(b ? "b" : "null"); This program outputs: a null What? I suppose this is by design, but are there any plans to deprecate this? A compiler change disallowin

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On Thursday, 20 August 2015 at 16:44:44 UTC, H. S. Teoh wrote: On Thu, Aug 20, 2015 at 04:22:20PM +, Jonathan M Davis via Digitalmars-d wrote: [...] I really don't mind NaN. It really doesn't cause problems normally. The problem with floating point values is floating point values themselves

string <-> null/bool implicit conversion

Hi! string a = ""; string b; writeln(a ? "a" : "null"); writeln(b ? "b" : "null"); This program outputs: a null What? I suppose this is by design, but are there any plans to deprecate this? I understand this happens because in this context, string.ptr is evaluated, but should a string

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On Thu, Aug 20, 2015 at 04:22:20PM +, Jonathan M Davis via Digitalmars-d wrote: [...] > I really don't mind NaN. It really doesn't cause problems normally. > The problem with floating point values is floating point values > themselves. They're so painfully inexact. Even without NaN, you can't

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On Thursday, 20 August 2015 at 14:52:53 UTC, renoX wrote: On Wednesday, 19 August 2015 at 14:01:34 UTC, Jonathan M Davis wrote: Yeah. I guess that the floating point stuff doesn't quite work that way thanks to NaN. *sigh* I hate floating point numbers. Sometimes, you have no choice other than u

Re: Idiomatic snippets

Thanks to your contributions, in only a couple of minutes D jumped at the 10th position of the most populated language in the site. Great!! 6th position actually! Another couple of minutes later. You guys rock.

Re: Idiomatic snippets

Very good suggestions. I'll use the Github tracker to manage them : https://github.com/Deleplace/programming-idioms/issues/1 (dice icon) https://github.com/Deleplace/programming-idioms/issues/2 (link to doc) Yes the website partially overlaps the purpose of Rosetta Code, but still has a lot

Re: Idiomatic snippets

On 8/20/15 9:27 AM, Val wrote: Hello Developers I set up a website about how one would perform common programming tasks in the most idiomatic form in different languages. It is intended to be didactic, it's open to contributions (like a wiki) and we'd love to have more snippets written in D. It w

Re: Idiomatic snippets

On Thursday, 20 August 2015 at 13:28:00 UTC, Val wrote: Hello Developers I set up a website about how one would perform common programming tasks in the most idiomatic form in different languages. It is intended to be didactic, it's open to contributions (like a wiki) and we'd love to have more

Re: [OT] Sharp Regrets: Top 10 Worst C# Features

On Wednesday, 19 August 2015 at 14:01:34 UTC, Jonathan M Davis wrote: Yeah. I guess that the floating point stuff doesn't quite work that way thanks to NaN. *sigh* I hate floating point numbers. Sometimes, you have no choice other than using them, but man are they annoying. - Jonathan M Davis

Re: An Unusual Idea: import std;

On 08/19/2015 10:19 AM, Kagamin wrote: http://forum.dlang.org/post/mmntkn$9ta$1...@digitalmars.com ? More specifically: https://github.com/Abscissa/scriptlike/blob/master/src/scriptlike/std.d import scriptlike.std; I'd really like to see this happen though, as it would make scriptlike a lo

Re: Presentation Intro to D: What works?

Am 20.08.2015 um 15:06 schrieb yawniek: > On Wednesday, 19 August 2015 at 20:15:48 UTC, qznc wrote: >> On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: >> If you are interested in my slides: >> >> http://beza1e1.tuxen.de/stuff/FunctionalD.odp >> http://beza1e1.tuxen.de/stuff/FunctionalD.pdf >

Re: Presentation Intro to D: What works?

On Wednesday, 19 August 2015 at 20:15:48 UTC, qznc wrote: On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: [...] Presentation done. Only six people in the audience, but they appreciated it. 5/6 already had heard about D. 3/6 had played with it. If you are interested in my slides: ht

Idiomatic snippets

Hello Developers I set up a website about how one would perform common programming tasks in the most idiomatic form in different languages. It is intended to be didactic, it's open to contributions (like a wiki) and we'd love to have more snippets written in D. It would hugely help if a few of

Re: Presentation Intro to D: What works?

On Wednesday, 19 August 2015 at 20:15:48 UTC, qznc wrote: On Thursday, 25 June 2015 at 12:39:11 UTC, qznc wrote: If you are interested in my slides: http://beza1e1.tuxen.de/stuff/FunctionalD.odp http://beza1e1.tuxen.de/stuff/FunctionalD.pdf I spent some time on D history and philosophy. Mostly

Re: cannot initialize static array by static this()

On Thursday 20 August 2015 08:33, aki wrote: > Is this a bug? Yes. Please file a bug at .

Re: 2.068.0 regression?

On 08/20/2015 12:46 PM, Timon Gehr wrote: - No hiding of imported symbols by less deeply nested ones; enclosing scopes are treated the same way as imports. (for overloading, not for lookup.)

Re: 2.068.0 regression?

On 08/20/2015 05:55 AM, Andrei Alexandrescu wrote: We need to fix the implementation. We can't promote imports that hide local symbols. -- Andrei Great! We should probably agree on the precise new semantics first though. The current viable proposals in the bug report are: - The symbols decla