www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta D 2.069.0-b1

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
First beta for the 2.069.0 release.

http://dlang.org/download.html#dmd_beta
http://dlang.org/changelog/2.069.0.html

Please report any bugs at https://issues.dlang.org

-Martin
Oct 07 2015
next sibling parent reply extrawurst <stephan extrawurst.org> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
`The -property switch has been deprecated.` Does that mean property has no effect anymore ? --Stephan
Oct 07 2015
next sibling parent reply Andrea Fontana <nospam example.com> writes:
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
`The -property switch has been deprecated.` Does that mean property has no effect anymore ? --Stephan
From changelog: "The -property switch used to disallow calling non-properties without parentheses. The switch has not been used to build Phobos for some time now. So naturally, code that's incompatible with -property has found its way in. This means, the switch has effectively not been supported by D at large. Since the behaviour of the -property switch was not well-liked, it's been deprecated and made to have no effect when used."
Oct 08 2015
parent extrawurst <stephan extrawurst.org> writes:
On Thursday, 8 October 2015 at 07:25:36 UTC, Andrea Fontana wrote:
 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 [...]
`The -property switch has been deprecated.` Does that mean property has no effect anymore ? --Stephan
From changelog: "The -property switch used to disallow calling non-properties without parentheses. The switch has not been used to build Phobos for some time now. So naturally, code that's incompatible with -property has found its way in. This means, the switch has effectively not been supported by D at large. Since the behaviour of the -property switch was not well-liked, it's been deprecated and made to have no effect when used."
Thanks to clear that up. --Stephan
Oct 09 2015
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 Does that mean  property has no effect anymore ?
property never actually worked anyway. It is still my hope that it will be correctly implemented some day though - the hard problem it was meant to solve is still there (returning delegates from properties, the other things are all minor stylistic things, but this is outright breakage).
Oct 08 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:
 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 Does that mean  property has no effect anymore ?
property never actually worked anyway. It is still my hope that it will be correctly implemented some day though
I think http://wiki.dlang.org/DIP23 reflects the most accurate roadmap for property, basically being permissive w.r.t. parens. And who really cares whether it's rng.popFront or rng.popFront()?
Oct 08 2015
parent reply Jonathan M Davis via Digitalmars-d-announce writes:
On Thursday, October 08, 2015 15:00:15 Martin Nowak via Digitalmars-d-announce
wrote:
 On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote:
 On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 Does that mean  property has no effect anymore ?
property never actually worked anyway. It is still my hope that it will be correctly implemented some day though
I think http://wiki.dlang.org/DIP23 reflects the most accurate roadmap for property, basically being permissive w.r.t. parens. And who really cares whether it's rng.popFront or rng.popFront()?
What's problematic with regards to requiring parens or not is when the symbol _can't_ be called with parens. So, whether popFront is called with parens or not realistically doesn't matter, because it's going to be a function (theoretically, it could be a member variable that implements opCall, but that's so unlikely that there really is no need to worry about it IMHO). However, it _does_ matter whether something that's intended to be used as a property or not is called with parens. Code which uses parens on save or front is not going to work with all ranges, because they're not always functions. So - at least in templated code - it needs to be clear when a symbol is treated as a property, and it cannot be called with parens if it is supposed to be a property. Enforcing that property is called without parens wouldn't entirely fix that problem, but it would help catch cases where someone actually used parens when they shouldn't have. Regardless, what we pretty much need to do with property at some point is make is that it's used to make it so that a single pair of parens operate on the return value rather than the function even if we don't do anything else with property - otherwise properties which are delegates or other callables aren't possible. Having DIP 23 be implemented would be great though. - Jonathan M Davis
Oct 09 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 October 2015 at 01:27:09 UTC, Jonathan M Davis 
wrote:
 Regardless, what we pretty much need to do with  property at 
 some point is make is that it's used to make it so that a 
 single pair of parens operate on the return value rather than 
 the function even if we don't do anything else with  property
Right, ideally a proptery function can perfectly replace a variable, but practically calling the return value seems far fetched. What would you use that for, a handwritten interface struct with function pointers made read-only using property? To me the whole property discussion looks like one of those endless debates about an insignificant detail. Scala and Ruby seem to do well with sloppy parens. With the introduction of UFCS it became clear that nobody likes byLine().array().sort().release(), and even less rng.release.sort().array().front. For some functions it's really hard to decide whether or not something is a property, e.g. for me Range.save is an action/function not a property. So for me using property appears to waste time making pointless decisions.
Oct 09 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?
var a = var.emptyObject; // works today a.prop = { do_stuff; }; // works today a.prop(); // useless no op a.prop()(); // this is needed That one case alone is all I care about property for.
Oct 09 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 10 October 2015 at 02:15:14 UTC, Adam D. Ruppe wrote:
 On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak 
 wrote:
 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?
var a = var.emptyObject; // works today a.prop = { do_stuff; }; // works today a.prop(); // useless no op a.prop()(); // this is needed That one case alone is all I care about property for.
That's what I meant, weird use-case, at best it's a callback better/setter. I've never written such code, but even if you would, the 2 pairs of parens are only a tiny problem for generic code, nothing to warrant the invasive language feature property is.
Oct 09 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
 nothing to warrant the invasive language feature  property is.
There's no reason for property to be invasive. ALL it needs to do is handle that one case, it shouldn't even be used anywhere else. Everything else is trivial or irrelevant. And the beauty of this is it won't even break any code.
Oct 09 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/9/15 10:37 PM, Adam D. Ruppe wrote:
 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
 nothing to warrant the invasive language feature  property is.
There's no reason for property to be invasive. ALL it needs to do is handle that one case, it shouldn't even be used anywhere else. Everything else is trivial or irrelevant. And the beauty of this is it won't even break any code.
I honestly couldn't care less about this. What I don't like is arbitrary setter property abuse. e.g. somerange.find = needle; My opinion: Empty parens can always be omitted on functions, but need to be present in order to call delegates/function pointers. property function on struct/class method enables the instance.method = value; syntax. Otherwise, it's rejected (you must use instance.method(value); syntax). If I were defining it from scratch, I'd say you HAVE to use first syntax if it's marked property, but I'm OK with allowing the normal syntax on property methods. Since we have property, slapping it on a getter that returns a delegate/function pointer enables the behavior you want (why not?). &instance.prop I'm unsure what it should mean. I'm leaning towards that it means get a delegate to the property method itself, not the result of calling the property. This makes it behave differently than a field, but it already does this today. property on module level functions operate like methods, but allow UFCS calls. So: 0 params -> Obviously, like a getter (see above). 1 params -> Allow func = val syntax. Other syntaxes still allowed. Calling val.func syntax, if returning a delegate, I think should require the double parens, since IMO property is for the setter syntax, not a description of a UFCS call. 2 params -> Allow firstParam.func = secondParam syntax. Other syntaxes still allowed. -Steve
Oct 15 2015
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.
I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens. Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.
Oct 09 2015
next sibling parent Jonathan M Davis via Digitalmars-d-announce writes:
On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote:
 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote:
 That's what I meant, weird use-case, at best it's a callback
 better/setter.
 I've never written such code, but even if you would, the 2
 pairs of parens are only a tiny problem for generic code,
 nothing to warrant the invasive language feature  property is.
I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens.
Optional parens definitely do not help with generic code - quite the opposite. In generic code, it needs to be clear whether a symbol is supposed to represent a field or a function. If it's a field, you call it without parens. If it's a function, it has to be called with parens if it's supposed to be possible to have the symbol emulate a function rather than be a function (e.g. be a delegate). We mostly get away with optional parens on function calls in generic code, because it's pretty rare that we write code that's expecting a function and is given a delegate, except in the cases (like predicates) where we clearly expect any kind of callable, and we have to use template wrappers (e.g. std.functional.binary) in those cases in order to make them all act the same and not care about what exactly we're getting. For symbols that are supposed to act like fields, they can't be called with parens in generic code, or they won't work generically, and unlike with symbols that are supposed to act like functions, it's _very_ common to get a mix of variables and functions for the same symbol across different types. So, generic code that uses parens on what is supposed to be a field will work with a function but fail miserably if the type it's given implemented that symbol as a variable. And that's common enough that generic code needs to get it right, whereas it can mostly get away with it with symbols that represent functions simply due to the fact that they're pretty much always implemented as functions. I don't think that there's any question that generic code would be better off if we didn't have optional parens and if functions which used the property syntax weren't allowed to be called with parens. And D programs typically have a lot of generic code. The problem is that when folks are writing code that uses generic functions (rather than necessarily being inside of generic functions), they like to leave off the parens and think that it's ugly to be required to have them. So, we don't have full property enforcement and will never get it. But that same laxity inside of generic code easily leads to compilation failures when properties are used simply because a function will work with parens (be it an property function or not) whereas variables won't. Hands down, I think that we'd be better off with strict property enhancement due to all of the generic code that we deal with, but that water is long since under the brigde. Instead, we're forever going to be forced to be even more thorough with unit testing in order to make sure that templated functions don't use parens on symbols that are supposed to be properties/fields and to make sure that it does use parens on something that is supposed to be a function. Since, any time we don't do that, we risk making mistakes and writing generic code that doesn't work with all of the types that it's supposed to work with. The only question at this point is whether we can at least get partial property enforcement out of property and reduce the number of bugs in generic code or whether property is pretty much just going to be tossed out. - Jonathan M Davis
Oct 10 2015
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
 wrote:
 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.
I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens. Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.
To the next person that is going to say this is overblown, I ran into such bugs more than once in phobos. So, unless we expect most D developer to be better than phobos contributor, that is a problem.
Oct 10 2015
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 11 Oct 2015 01:54:39 +0000
schrieb deadalnix <deadalnix gmail.com>:

 On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
 On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak 
 wrote:
 That's what I meant, weird use-case, at best it's a callback 
 better/setter.
 I've never written such code, but even if you would, the 2 
 pairs of parens are only a tiny problem for generic code, 
 nothing to warrant the invasive language feature  property is.
I don't know how much metaprogramming-heavy generic code you've written, but I can say from first-hand experience that there is such a thing as Hell, and it is called Optional Parens. Jokes aside, I've finally fixed (read: worked around using awful hacks) a bug where the compiler was complaining about either "Type.memberFunction is not callable with arguments ()" or "Need 'this' for Type.memberFunction". I love optional parens in regular code, especially range-based code (doesn't everybody?), but I desperately want a way to ensure that the symbol that I'm trying to pass to a template function won't be interpreted as a function call instead.
To the next person that is going to say this is overblown, I ran into such bugs more than once in phobos. So, unless we expect most D developer to be better than phobos contributor, that is a problem.
We even have such a problem in object.d: https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461 I remember somebody asking in D.learn why his custom test runner did not work. Problem was related to wrong parenthesis: The user wrote mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't find the exact link right now.
Oct 11 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-11 11:45, Johannes Pfau wrote:

 We even have such a problem in object.d:

 https://github.com/D-Programming-Language/druntime/blob/master/src/object.d#L1461

 I remember somebody asking in D.learn why his custom test runner did
 not work. Problem was related to wrong parenthesis: The user wrote
 mod.unitTest() instead of mod.unitTest()() IIRC. Unfortunately I can't
 find the exact link right now.
That would be me :) [1]. I think the biggest issue was that something that worked before stopped working, because a field was changed to a method and the method returned a function pointer. [1] http://forum.dlang.org/thread/kaara7$dog$1 digitalmars.com#post-kaara7:24dog:241:40digitalmars.com -- /Jacob Carlborg
Oct 11 2015
parent Kagamin <spam here.lot> writes:
On Sunday, 11 October 2015 at 09:54:04 UTC, Jacob Carlborg wrote:
 That would be me :) [1]. I think the biggest issue was that 
 something that worked before stopped working, because a field 
 was changed to a method and the method returned a function 
 pointer.

 [1] 
 http://forum.dlang.org/thread/kaara7$dog$1 digitalmars.com#post-kaara7:24dog:241:40digitalmars.com
That refactoring is exactly the (only) use case for strict properties, they shouldn't be used in other cases.
Oct 13 2015
prev sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 10 October 2015 at 02:57:03 UTC, Meta wrote:
 I don't know how much metaprogramming-heavy generic code you've 
 written, but I can say from first-hand experience that there is 
 such a thing as Hell, and it is called Optional Parens.

 Jokes aside, I've finally fixed (read: worked around using 
 awful hacks) a bug where the compiler was complaining about 
 either "Type.memberFunction is not callable with arguments ()" 
 or "Need 'this' for Type.memberFunction". I love optional 
 parens in regular code, especially range-based code (doesn't 
 everybody?), but I desperately want a way to ensure that the 
 symbol that I'm trying to pass to a template function won't be 
 interpreted as a function call instead.
Well, in order to pass the result of a function call to a template parameter means that the function must be evaluated at compile time, which is not always possible, so it probably doesn't make sense to call a function when passed as a template argument.
Oct 13 2015
parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:
 Well, in order to pass the result of a function call to a 
 template parameter means that the function must be evaluated at 
 compile time, which is not always possible, so it probably 
 doesn't make sense to call a function when passed as a template 
 argument.
You'd be surprised what DMD thinks is a function call and what isn't.
Oct 13 2015
parent reply Kagamin <spam here.lot> writes:
On Tuesday, 13 October 2015 at 13:57:15 UTC, Meta wrote:
 On Tuesday, 13 October 2015 at 13:18:36 UTC, Kagamin wrote:
 Well, in order to pass the result of a function call to a 
 template parameter means that the function must be evaluated 
 at compile time, which is not always possible, so it probably 
 doesn't make sense to call a function when passed as a 
 template argument.
You'd be surprised what DMD thinks is a function call and what isn't.
What doesn't work for you? extern int f(); struct T(F){} T!f t; //Error: template instance T!(f) does not match template declaration T(F) struct A(alias F){} A!f a; //works
Oct 13 2015
parent Meta <jared771 gmail.com> writes:
On Tuesday, 13 October 2015 at 16:07:50 UTC, Kagamin wrote:
 What doesn't work for you?

 extern int f();
 struct T(F){}
 T!f t; //Error: template instance T!(f) does not match template 
 declaration T(F)
 struct A(alias F){}
 A!f a; //works
I don't remember. I fixed the issues a few weeks ago using various hackarounds. The main area that problems pop up is in metaprogramming where you don't know what you're working with (could be a member function, free function, template function, etc.). It's very hard to deal with optional parens generically, and you have to take special care to ensure that the compiler doesn't think you're calling a function when that's not what you meant to do.
Oct 14 2015
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
 To me the whole property discussion looks like one of those 
 endless debates about an insignificant detail.
 Scala and Ruby seem to do well with sloppy parens.
Strict typing and explicitness has a real effect on code legibility and maintenance. D is trying too hard to be a scripting language. Taking away getter/setter typing just reinforce that impression.
 With the introduction of UFCS it became clear that nobody likes 
 byLine().array().sort().release(), and even less 
 rng.release.sort().array().front.
Introduce a pipeline operator. Chaining processes with dot operators has always been an ugly old OO hack.
 For some functions it's really hard to decide whether or not 
 something is a property, e.g. for me Range.save is an 
 action/function not a property. So for me using  property 
 appears to waste time making pointless decisions.
If it is hard to decide then that probably means that the model is flawed and needs more work. D really needs to start strengthening the type system, rather than eroding it.
Oct 09 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-10 03:52, Martin Nowak wrote:

 Scala and Ruby seem to do well with sloppy parens.
A few notes about why Ruby doesn't have the same problems as D has: 1. Ruby has optional parentheses for all method calls, regardless if they accept arguments or not 2. Ruby has a different syntax for calling lambdas from calling functions: def foo end a = -> { } In Ruby, no one will ever use empty parentheses for calling a method. 3. You can not use the setter syntax for a "regular" method taking one argument: class Foo def bar(a) end end end a = Foo.new -- /Jacob Carlborg
Oct 10 2015
next sibling parent Iain Buclaw via Digitalmars-d-announce writes:
On 10 October 2015 at 14:51, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 2015-10-10 03:52, Martin Nowak wrote:

 Scala and Ruby seem to do well with sloppy parens.

 A few notes about why Ruby doesn't have the same problems as D has:

 1. Ruby has optional parentheses for all method calls, regardless if they
 accept arguments or not

 2. Ruby has a different syntax for calling lambdas from calling functions:

 def foo
 end



 a = -> { }



 In Ruby, no one will ever use empty parentheses for calling a method.

 3. You can not use the setter syntax for a "regular" method taking one
 argument:

 class Foo
   def bar(a)
   end


   end
 end

 a = Foo.new



It seems to be a misfeature of D to accept the equivalent of all three of those examples as valid.
Oct 10 2015
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
wrote:
 In Ruby, no one will ever use empty parentheses for calling a 
 method.
That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.
Oct 10 2015
parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
 wrote:
 In Ruby, no one will ever use empty parentheses for calling a 
 method.
That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.
That's actually quite beautiful in its simplicity.
Oct 10 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 11 October 2015 at 01:52:12 UTC, deadalnix wrote:
 On Saturday, 10 October 2015 at 16:31:27 UTC, Ola Fosheim 
 Grøstad wrote:
 On Saturday, 10 October 2015 at 12:51:43 UTC, Jacob Carlborg 
 wrote:
 In Ruby, no one will ever use empty parentheses for calling a 
 method.
That's actually the same as Simula. Functions/procedures with no parameters is called without parentheses.
That's actually quite beautiful in its simplicity.
It is ok, but I find it more confusing than the C syntax when using a plain text editor. With distinguishing syntax colouring it might work out better, it is one of those cases where an IDE could make a difference. Nygaard et al later improved on the uniformity of Simula in the language BETA by recognizing that a parameter list is the same as a tuple, with this syntax: input_tuple -> object_or_function -> output_tuple; (1,(2,3)) -> something1 -> something2 -> (a,b) (1,(2,3)) -> &run_concurrent_object Without any input tuple, one can naturally omit the input arrow. That also means that BETA does not distinguish between a function call and an assignment. An instanced object is just a function that persist state over calls, aka variable or a process/coroutine. A class type acts like a function when it called without being already instanced. So I think it provides better orthogonality than in C++/D where you can have both opCall and opAssign. The downside by having the consise BETA syntax and OO semantics is that you need to change how you conceptualize OO modelling. BETA has been generalized further in the academic language gbeta, which also have some dependent typing. Which is kind of interesting in relation to D, because it appears to be heavily built upon mixins: http://www.daimi.au.dk/~eernst/gbeta/
Oct 11 2015
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad 
wrote:
 That also means that BETA does not distinguish between a 
 function call and an assignment.
Hey, neither does D! writeln("Hello, World!"); writeln = "Hello, World!";
Oct 11 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:
 On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim Grøstad 
 wrote:
 That also means that BETA does not distinguish between a 
 function call and an assignment.
Hey, neither does D! writeln("Hello, World!"); writeln = "Hello, World!";
But BETA has a single syntax for it: "Hello, World!" -> writeln;
Oct 11 2015
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 11 October 2015 at 17:27:39 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 11 October 2015 at 16:42:36 UTC, Meta wrote:
 On Sunday, 11 October 2015 at 16:00:40 UTC, Ola Fosheim 
 Grøstad wrote:
 That also means that BETA does not distinguish between a 
 function call and an assignment.
Hey, neither does D! writeln("Hello, World!"); writeln = "Hello, World!";
But BETA has a single syntax for it: "Hello, World!" -> writeln;
Just a joke; I consider this a terrible aspect of D.
Oct 11 2015
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 11 October 2015 at 17:57:54 UTC, Meta wrote:
 Just a joke; I consider this a terrible  aspect of D.
:) I never know what is a joke or not in the forums these days. Anyway, a key difference is that a key inspiration for both BETA and also the actor model is modelling physical (or imaginary) world processes . In that context it makes sense to think of a variable as a "process/object" that can store what you send to it just like a printer is an "process/object" asked to print what you send to it. Most imperative languagedesign struggles with the stateful process vs pure math aspect of programming IMO.
Oct 11 2015
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Saturday, 10 October 2015 at 01:52:36 UTC, Martin Nowak wrote:
 Right, ideally a  proptery function can perfectly replace a 
 variable, but practically calling the return value seems far 
 fetched.
 What would you use that for, a handwritten interface struct 
 with function pointers made read-only using  property?
It doesn't matter. If you want an explosion of special cases, there is already a language for that, it is called C++. Every time an exception is introduced, the "burden of proof" is to prove this exception actually bring sufficient value to pay for itself, not the other way around.
 To me the whole property discussion looks like one of those 
 endless debates about an insignificant detail.
 Scala and Ruby seem to do well with sloppy parens.
For what I've touched of ruby, the language is very permissive and nice. This is good when you do your first prototype, but this is also what causes it to be intractable at scale (and also impossible to optimize, but that is beside the point here). Is the parentheses thing a problem ? Not really on its own, but it compound. The parentheses thing and with it the special _ syntax to NOT call a function is not considered as a good thing by most scala people I've talked to.
 With the introduction of UFCS it became clear that nobody likes 
 byLine().array().sort().release(), and even less 
 rng.release.sort().array().front.
 For some functions it's really hard to decide whether or not 
 something is a property, e.g. for me Range.save is an 
 action/function not a property. So for me using  property 
 appears to waste time making pointless decisions.
One can reach the desired effect by having a consistent set of rules and define the calling as a fallback rewrite when there is an error. Namely, add a rule that says : if this is an error, add () and retry. Here you go, problem solved, you can use parentheses function call in every places it is not ambiguous without introducing Byzantines set of rules into the language.
Oct 10 2015
prev sibling next sibling parent reply anonymous <anonymous example.com> writes:
On Thursday 08 October 2015 06:14, extrawurst wrote:

 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?
Yes. I've made a pull request to mention that (and put a note on the spec page). https://github.com/D-Programming-Language/dlang.org/pull/1119 We should probably try to finally find good semantics for property.
Oct 08 2015
parent anonymous <anonymous example.com> writes:
On Thursday 08 October 2015 16:34, anonymous wrote:

 On Thursday 08 October 2015 06:14, extrawurst wrote:
 
 `The -property switch has been deprecated.` Does that mean 
  property has no effect anymore ?
Yes.
Correction: property has at least one effect without -property. typeof acts differently on properties vs non-properties. ---- struct S { property int p(); int n(); } pragma(msg, typeof(S.init.p)); /* int */ pragma(msg, typeof(S.init.n)); /* int() -- i.e. a function */ ---- I wasn't aware of this before Jonathan M Davis told me [1]. I don't think it's specified anywhere, at least I can't find anything. [1] https://github.com/D-Programming-Language/dlang.org/pull/1119#issuecomment-146576866
Oct 08 2015
prev sibling parent ponce <contact gam3sfrommars.fr> writes:
On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
`The -property switch has been deprecated.` Does that mean property has no effect anymore ? --Stephan
Now it would be great if property was removed. It is just one more attribute that brings nothing to the table and take valuable space on the screen.
Oct 08 2015
prev sibling next sibling parent reply Suliman <evermind live.ru> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Is it DDMD based release?
Oct 07 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:
 Is it DDMD based release?
Yes.
Oct 08 2015
next sibling parent reply lobo <swamplobo gmail.com> writes:
On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:
 On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:
 Is it DDMD based release?
Yes.
Is there any info on the benchmarking between DDMD and DMD? bye, lobo PS: Big thanks for the much improved release process that you guys are maintaining.
Oct 08 2015
next sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 10/08/2015 11:36 AM, lobo wrote:
 
 Is there any info on the benchmarking between DDMD and DMD?
Still on the todo list to decide whether we need to use gdc to build ddmd. https://trello.com/c/OT6jlFNa/85-rebench-ddmd-vs-dmd-compiler-speed
Oct 08 2015
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 8 October 2015 at 09:36:31 UTC, lobo wrote:
 PS: Big thanks for the much improved release process that you 
 guys are maintaining.
I agree. Thank you, Martin.
Oct 08 2015
prev sibling parent reply Andrea Fontana <nospam example.com> writes:
On Thursday, 8 October 2015 at 09:17:16 UTC, Martin Nowak wrote:
 On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:
 Is it DDMD based release?
Yes.
Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 2.068.2?
Oct 08 2015
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana wrote:
 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
 2.068.2?
The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so).
Oct 08 2015
parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote:
 On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana 
 wrote:
 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with dmd 
 2.068.2?
The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so).
One does not exclude the other. You could still re-build 2.069b1 using itself. — David
Oct 08 2015
parent Andrea Fontana <nospam example.com> writes:
On Thursday, 8 October 2015 at 15:04:08 UTC, David Nadlinger 
wrote:
 On Thursday, 8 October 2015 at 15:01:31 UTC, Martin Nowak wrote:
 On Thursday, 8 October 2015 at 12:20:23 UTC, Andrea Fontana 
 wrote:
 Are dmd 2.069b1 binaries compiled with dmd 2.069b1 or with 
 dmd 2.068.2?
The last released compiler, we don't have any bootstrap method (using a small C++ compiler or so).
One does not exclude the other. You could still re-build 2.069b1 using itself. — David
Sure, just to know which option is used. I think rebuilding 2.069b1 with 2.069b1 could help to find bugs and, of course, can takes advantages from the new improvements... am I missing something?
Oct 09 2015
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
08.10.2015 01:33, Martin Nowak пишет:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Cool! References to `cmp`, `std.experimental.allocator` reference to current phobos, not prerelease one. I tryied to modify the page but can't find info about used macros to do it.
Oct 07 2015
prev sibling next sibling parent Tourist <gravatar gravatar.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
The "libcurl is now loaded dynamically" link is broken.
Oct 08 2015
prev sibling next sibling parent Andrea Fontana <nospam example.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Got an issue: https://issues.dlang.org/show_bug.cgi?id=15177 It's really strange and difficult to reduce for me...
Oct 08 2015
prev sibling next sibling parent Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Thanks! Please add the PR about allocators for the next beta https://github.com/D-Programming-Language/phobos/pull/3684 -Ilya
Oct 08 2015
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Am I being dumb or does SYSCONFDIR do absolutely nothing...
Oct 08 2015
parent John Colvin <john.loughran.colvin gmail.com> writes:
On Thursday, 8 October 2015 at 12:32:59 UTC, John Colvin wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Am I being dumb or does SYSCONFDIR do absolutely nothing...
https://issues.dlang.org/show_bug.cgi?id=15181
Oct 09 2015
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
I think it should be mentioned in the change log the substantial improvements that were made to the docs since last release. After over 30 PRs were merged for improving the docs, they are WAY better than the 2.068 docs.
Oct 08 2015
parent Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 14:59:15 UTC, Jack Stouffer wrote:
 I think it should be mentioned in the change log the 
 substantial improvements that were made to the docs since last 
 release. After over 30 PRs were merged for improving the docs, 
 they are WAY better than the 2.068 docs.
Sure, just add it to the changelog. https://github.com/D-Programming-Language/dlang.org/pull/1118
Oct 08 2015
prev sibling next sibling parent reply ponce <contact gam3sfrommars.fr> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.
Weren't there codegen improvements in DMD?
Oct 08 2015
parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 8 October 2015 at 16:12:52 UTC, ponce wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 First beta for the 2.069.0 release.
Weren't there codegen improvements in DMD?
https://github.com/D-Programming-Language/dlang.org/pull/1121
Oct 08 2015
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/07/2015 06:33 PM, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
Can we please get this one in?: https://github.com/D-Programming-Language/dmd/pull/4745 I'm getting tired of watching, updating and rebasing it, and also tired of the paragraphs in my generated docs being all messed up.
Oct 08 2015
prev sibling next sibling parent reply NVolcz <niklas.volcz gmail.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
The changelog links to: http://dlang.org/phobos/std_experimental_allocator.html which returns 404 for me. I remember seeing discussions about versioning the docs. What happened to that?
Oct 08 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/8/15 4:59 PM, NVolcz wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
The changelog links to: http://dlang.org/phobos/std_experimental_allocator.html which returns 404 for me. I remember seeing discussions about versioning the docs. What happened to that?
This is because the current docs are for the current release, not the to-be-released version. Try http://dlang.org/phobos-prerelease/std_experimental_allocator.html -Steve
Oct 08 2015
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Thursday, 8 October 2015 at 20:59:57 UTC, NVolcz wrote:
 The changelog links to:
 http://dlang.org/phobos/std_experimental_allocator.html
 which returns 404 for me.
 I remember seeing discussions about versioning the docs. What 
 happened to that?
Fixed by now.
Oct 08 2015
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
I just noticed that you added the beta to the main download page, nice move, probably overdue. Has it increased the downloads much? Maybe you should add a warning there, for those who may not know the meaning of a beta.
Oct 09 2015
parent Andrea Fontana <nospam example.com> writes:
On Friday, 9 October 2015 at 09:32:05 UTC, Joakim wrote:
 downloads much?  Maybe you should add a warning there, for 
 those who may not know the meaning of a beta.
If you're a coder you know what it means. If you just started with programming probably it doesn't make any difference :)
Oct 09 2015
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
First beta, so far I can use it as a drop in replacement. Nothing broke. It's like magic :) Very good job :)
Oct 10 2015
prev sibling next sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
brew reinstall dmd --devel :) thanks for all the hard work
Oct 12 2015
prev sibling parent reply ZombineDev <valid_email he.re> writes:
On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
I decided to try the newly included mscoff 32 Phobos. For this purpouse I create a D struct, whose members I call in C++. This works in Linux, so any issues should be windows specific. My directory has the following files: test_struct.d main.cpp I did the following: 1) Installed DMD v2.069.0-b1 with the installer 2) Started VS2015 x86 Native Tools Command Prompt 3) Executed the following commands: dmd -c -m32mscoff test_struct.d cl main.cpp test_struct.obj C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib And got the following error: main.cpp phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved exter nal symbol __minfo_beg referenced in function _D2rt14sections_win6414getModuleIn fosFZAyPS6object10ModuleInfo phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved exter nal symbol __minfo_end referenced in function _D2rt14sections_win6414getModuleIn fosFZAyPS6object10ModuleInfo phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: unresolved external symb ol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAx aKfZb phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: unresolved external symb ol _sscanf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaK fZb hw0_cpp.exe : fatal error LNK1120: 4 unresolved externals I have declared the druntime hooks like this: extern "C" int rt_init(); extern "C" void rt_term(); P.S. I decided to try something simpler: A single .cpp file that calls rt_init() and rt_term() and nothing else. I tried the following: cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib And I got the same error message. Any idea what's going wrong?
Oct 13 2015
parent reply ZombineDev <valid_email he.re> writes:
On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
 On Wednesday, 7 October 2015 at 22:33:09 UTC, Martin Nowak 
 wrote:
 First beta for the 2.069.0 release.

 http://dlang.org/download.html#dmd_beta 
 http://dlang.org/changelog/2.069.0.html

 Please report any bugs at https://issues.dlang.org

 -Martin
I decided to try the newly included mscoff 32 Phobos. For this purpouse I create a D struct, whose members I call in C++. This works in Linux, so any issues should be windows specific. My directory has the following files: test_struct.d main.cpp I did the following: 1) Installed DMD v2.069.0-b1 with the installer 2) Started VS2015 x86 Native Tools Command Prompt 3) Executed the following commands: dmd -c -m32mscoff test_struct.d cl main.cpp test_struct.obj C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib And got the following error: main.cpp phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved exter nal symbol __minfo_beg referenced in function _D2rt14sections_win6414getModuleIn fosFZAyPS6object10ModuleInfo phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved exter nal symbol __minfo_end referenced in function _D2rt14sections_win6414getModuleIn fosFZAyPS6object10ModuleInfo phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: unresolved external symb ol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAx aKfZb phobos32mscoff.lib(config_48f_452.obj) : error LNK2019: unresolved external symb ol _sscanf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaK fZb hw0_cpp.exe : fatal error LNK1120: 4 unresolved externals
Edit - read this as: main.exe : fatal error LNK1120: 4 unresolved externals
 I have declared the druntime hooks like this:
 extern "C" int rt_init();
 extern "C" void rt_term();

 P.S. I decided to try something simpler:
 A single .cpp file that calls rt_init() and rt_term() and 
 nothing else. I tried the following:
 cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib
 And I got the same error message.

 Any idea what's going wrong?
Oct 13 2015
parent reply ZombineDev <valid_email he.re> writes:
On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:
 On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
 [...]
Is the problem related to the new CRT in VS2015? Previously I thought that the problem is 64-bit only, but it seams like it is for both 32-bit and 64-bit MSCOFF. With the VS2015 x64 Native Tools Command Prompt I did: cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib And got: main.cpp phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved external sy mbol _minfo_beg referenced in function _D2rt14sections_win6414getModuleInfosFZAy PS6object10ModuleInfo phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved external sy mbol _minfo_end referenced in function _D2rt14sections_win6414getModuleInfosFZAy PS6object10ModuleInfo phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved external sy mbol _deh_beg referenced in function _D2rt14sections_win6412SectionGroup8ehTable sMxFNdZAyS2rt15deh_win64_posix9FuncTable phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved external sy mbol _deh_end referenced in function _D2rt14sections_win6412SectionGroup8ehTable sMxFNdZAyS2rt15deh_win64_posix9FuncTable phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external symbol snp rintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external symbol ssc anf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb main.exe : fatal error LNK1120: 6 unresolved externals AFAIR, the support for VS2015 CRT was merged and is included in this release, correct?
Oct 13 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 13.10.2015 21:44, ZombineDev wrote:
 On Tuesday, 13 October 2015 at 19:17:27 UTC, ZombineDev wrote:
 On Tuesday, 13 October 2015 at 19:14:51 UTC, ZombineDev wrote:
 [...]
Is the problem related to the new CRT in VS2015? Previously I thought that the problem is 64-bit only, but it seams like it is for both 32-bit and 64-bit MSCOFF.
The library issues are the same for 32-bit and 64-bit.
 With the VS2015 x64 Native Tools Command Prompt I did:
 cl main.cpp C:\D\dmd2\windows\lib64\phobos64.lib

 And got:

 main.cpp
 phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
 external sy
 mbol _minfo_beg referenced in function
 _D2rt14sections_win6414getModuleInfosFZAy
 PS6object10ModuleInfo
 phobos64.lib(sections_win64_6c9_5a5.obj) : error LNK2019: unresolved
 external sy
 mbol _minfo_end referenced in function
 _D2rt14sections_win6414getModuleInfosFZAy
 PS6object10ModuleInfo
 phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
 external sy
 mbol _deh_beg referenced in function
 _D2rt14sections_win6412SectionGroup8ehTable
 sMxFNdZAyS2rt15deh_win64_posix9FuncTable
 phobos64.lib(sections_win64_6c3_4e2.obj) : error LNK2019: unresolved
 external sy
 mbol _deh_end referenced in function
 _D2rt14sections_win6412SectionGroup8ehTable
 sMxFNdZAyS2rt15deh_win64_posix9FuncTable
 phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
 symbol snp
 rintf referenced in function
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
 phobos64.lib(config_48f_452.obj) : error LNK2019: unresolved external
 symbol ssc
 anf referenced in function
 _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb
 main.exe : fatal error LNK1120: 6 unresolved externals

 AFAIR, the support for VS2015 CRT was merged and is included in this
 release, correct?
Yes, but there is some magic involved when linking against the VS2015 CRT. To use symbols like snprintf and sscanf, you must also pass legacy_stdio_definitions.lib to the linker, which is done automatically if you use dmd as a frontend to the linker, but not cl. Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted by the compiler if you compile main, WinMain or DllMain. Unfortunately, compiling D's main also generates a C-style main, so it's not so easy to get these symbols if you need main in C/C++. I would currently recommend to write main in D, and call into C/C++ from there.
Oct 13 2015
next sibling parent reply Szymon Gatner <noemail gmail.com> writes:
On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
wrote:
 On 13.10.2015 21:44, ZombineDev wrote:
 [...]
The library issues are the same for 32-bit and 64-bit.
 [...]
Yes, but there is some magic involved when linking against the VS2015 CRT. To use symbols like snprintf and sscanf, you must also pass legacy_stdio_definitions.lib to the linker, which is done automatically if you use dmd as a frontend to the linker, but not cl. Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted by the compiler if you compile main, WinMain or DllMain. Unfortunately, compiling D's main also generates a C-style main, so it's not so easy to get these symbols if you need main in C/C++. I would currently recommend to write main in D, and call into C/C++ from there.
I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Br vo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012
Oct 14 2015
next sibling parent reply Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner 
wrote:
 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
 wrote:
 [...]
I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Br vo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012
Update: Linking with static D library under Visual Studio 2015 works fine (which is great). I do need to make it work under VS 2012 tho. Ideas?
Oct 14 2015
parent Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 14 October 2015 at 12:05:28 UTC, Szymon Gatner 
wrote:
 On Wednesday, 14 October 2015 at 11:39:26 UTC, Szymon Gatner 
 wrote:
 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
 wrote:
 [...]
I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Br vo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1 _minfo_beg, _minfo_end problems were solved by adding main() to D library so this is only porblem left. I am using Visual Studio 2012
Update: Linking with static D library under Visual Studio 2015 works fine (which is great). I do need to make it work under VS 2012 tho. Ideas?
Another Update: a bug I reported many moons ago is still there when mixing C++ with D. I updated the issue: https://issues.dlang.org/show_bug.cgi?id=14327
Oct 14 2015
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.10.2015 13:39, Szymon Gatner wrote:
 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:
 On 13.10.2015 21:44, ZombineDev wrote:
 [...]
The library issues are the same for 32-bit and 64-bit.
 [...]
Yes, but there is some magic involved when linking against the VS2015 CRT. To use symbols like snprintf and sscanf, you must also pass legacy_stdio_definitions.lib to the linker, which is done automatically if you use dmd as a frontend to the linker, but not cl. Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted by the compiler if you compile main, WinMain or DllMain. Unfortunately, compiling D's main also generates a C-style main, so it's not so easy to get these symbols if you need main in C/C++. I would currently recommend to write main in D, and call into C/C++ from there.
I am trying (as with every new release ;)) to link static D library to existing C++ project and I am having same issue: Error 2 error LNK2019: unresolved external symbol _snprintf referenced in function _D2gc6config13__T5parseHTfZ5parseFNbNiAxaKAxaKfZb C:\Users\Bravo\documents\visual studio 2012\Projects\ConsoleApplication1\ConsoleApplication1\phobos32mscoff.lib(config_48f_452.obj) ConsoleApplication1
I just noticed that the magic symbol translation _snprintf -> __snprintf isn't included without linking the internal function init_msvc (which is normally done by d_run_main which is called by the generated C main). The current workaround here is to add extern "C" void __cdecl init_msvc(); to the C source and call it before rt_init. I think we should move it into rt_init inside druntime.
Oct 14 2015
parent reply Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 14 October 2015 at 12:35:30 UTC, Rainer Schuetze 
wrote:
 I just noticed that the magic symbol translation _snprintf -> 
 __snprintf isn't included without linking the internal function 
 init_msvc (which is normally done by d_run_main which is called 
 by the generated C main).

 The current workaround here is to add

 extern "C" void __cdecl init_msvc();

 to the C source and call it before rt_init. I think we should 
 move it into rt_init inside druntime.
This indeed helps, thanks! There is new problem: creating a class instance on D side, then passing it to C++ and then back to D causes casting errors. My Example (based on Adam Ruppe's example): C++ file: #include <iostream> #include <stdio.h> extern "C" int rt_init(); extern "C" void rt_term(); extern "C++" int sumInD(int a, int b); extern "C++" void printHelloInD(); class Operation { public: virtual ~Operation() {} virtual int execute(int a, int b) = 0; }; class Add : public Operation { int execute(int a, int b) override { return a + b; } }; extern "C++" void useOperation(Operation* t); extern "C++" Operation* getSubtract(); extern "C++" void freeSubtract(Operation* cat); struct DRuntime { DRuntime() { if (!rt_init())\ { throw std::runtime_error("D Initialization failed"); } } ~DRuntime() { rt_term(); } }; void main() { DRuntime druntime; Add add; useOperation(&add); Operation* sub = getSubtract(); auto value = sub->execute(5, 3); freeSubtract(sub); } D library: module lib; import std.stdio; import core.stdc.stdlib; int main() { return 0; } extern(C++) interface Operation { void _destructorDoNotUse(); int execute(int a, int b); } class Subtract : Operation { extern(C++) void _destructorDoNotUse() {} extern(C++) int execute(int a, int b) {return a - b;} } extern(C++) Operation getSubtract() { import std.conv; enum size = __traits(classInstanceSize, Subtract); auto memory = malloc(size)[0 .. size]; return emplace!Subtract(memory); } extern (C++) int sumInD(int a, int b) { return a + b; } extern (C++) void printHelloInD() { writeln("Hello From D!"); << ===== throws exception (bug reported) } extern(C++) void freeSubtract(Operation animal) { auto cat = cast(Subtract) animal; <<====== cast yields null if(cat !is null) { destroy(cat); free(cast(void*) cat); } } extern(C++) void useOperation(Operation t) { auto res = t.execute(1, 2); } Everything works fine except the marked line. Subtract instance seems to be created correctly on D side as it returns valid result in the execute() call on C++ side but then when trying to free the instance on D side again, downcast from Operation to Subtract fails resulting in null.
Oct 14 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.10.2015 14:57, Szymon Gatner wrote:
 extern(C++)
 void freeSubtract(Operation animal) {
    auto cat = cast(Subtract) animal; <<====== cast yields null
    if(cat !is null) {
      destroy(cat);
      free(cast(void*) cat);
    }
 }

 extern(C++)
 void useOperation(Operation t) {
    auto res = t.execute(1, 2);
 }

 Everything works fine except the marked line. Subtract instance seems to
 be created correctly on D side as it returns valid result in the
 execute() call on C++ side but then when trying to free the instance on
 D side again, downcast from Operation to Subtract fails resulting in null.
To get compatible class layout, the D compiler has to omit it's class info entry in the vtable of C++ classes. In addition D doesn't know about C++ RTTI (I don't know if this is planned to add), so it cannot do the dynamic cast from Operation to Subtract. I have not tried, but calling the virtual destructor instead of destroy() might just work?
Oct 14 2015
parent reply Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 14 October 2015 at 13:12:00 UTC, Rainer Schuetze 
wrote:
 On 14.10.2015 14:57, Szymon Gatner wrote:
 extern(C++)
 void freeSubtract(Operation animal) {
    auto cat = cast(Subtract) animal; <<====== cast yields null
    if(cat !is null) {
      destroy(cat);
      free(cast(void*) cat);
    }
 }

 extern(C++)
 void useOperation(Operation t) {
    auto res = t.execute(1, 2);
 }

 Everything works fine except the marked line. Subtract 
 instance seems to
 be created correctly on D side as it returns valid result in 
 the
 execute() call on C++ side but then when trying to free the 
 instance on
 D side again, downcast from Operation to Subtract fails 
 resulting in null.
To get compatible class layout, the D compiler has to omit it's class info entry in the vtable of C++ classes. In addition D doesn't know about C++ RTTI (I don't know if this is planned to add), so it cannot do the dynamic cast from Operation to Subtract. I have not tried, but calling the virtual destructor instead of destroy() might just work?
Mint that this code comes from Adam Ruppe's book, and it is suppose to be working code. Also mind that Subtract is D class and instantiated on D side, it is only briefly passed to C++ for usage.
Oct 14 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.10.2015 15:26, Szymon Gatner wrote:
 To get compatible class layout, the D compiler has to omit it's class
 info entry in the vtable of C++ classes. In addition D doesn't know
 about C++ RTTI (I don't know if this is planned to add), so it cannot
 do the dynamic cast from Operation to Subtract.

 I have not tried, but calling the virtual destructor instead of
 destroy() might just work?
Mint that this code comes from Adam Ruppe's book, and it is suppose to be working code. Also mind that Subtract is D class and instantiated on D side, it is only briefly passed to C++ for usage.
Check the disassembly: the compiler is not even trying to do a conversion, it just loads null. There is no usable type information in a C++ interface. If you know the object "animal" is of type Subtract, you can get the object pointer by manually subtracting the pointer difference from the passed pointer: auto ptr = cast(void*)animal; ptr -= cast(void*)cast(Operation)cast(Subtract)ptr - ptr; auto cat = cast(Subtract) ptr;
Oct 14 2015
prev sibling parent reply ZombineDev <valid_email he.re> writes:
On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze 
wrote:
 Yes, but there is some magic involved when linking against the 
 VS2015 CRT. To use symbols like snprintf and sscanf, you must 
 also pass legacy_stdio_definitions.lib to the linker, which is 
 done automatically if you use dmd as a frontend to the linker, 
 but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only 
 emitted by the compiler if you compile main, WinMain or 
 DllMain. Unfortunately, compiling D's main also generates a 
 C-style main, so it's not so easy to get these symbols if you 
 need main in C/C++.

 I would currently recommend to write main in D, and call into 
 C/C++ from there.
Thanks for the answer. Just for the reference, under VS2015 x86 Native Tools Command Prompt I tried to link a C++ main function that only calls rt_init() and rt_term() like this: cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib" I got: main.cpp phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_beg referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_end referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo main.exe : fatal error LNK1120: 2 unresolved externals Which, based on your answer, is expected. I'm looking into integrating D into an existing C++ build and I need to statically link the D library. So my next questions are: 1) Where can I find legacy_stdio_definitions.lib? P.S.: It's included in VS (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib) 2) How can I workaround the problem that _minfo* and _deh* are not generated because my main is in C++? Basically what's preventing me from using D main is that one of the C++ libraries I use creates threads and dispatches functions to run on them in manner similar to Boost ASIO, and I don't have control over this proprietary library. To me, the fact that consuming D libraries from C++ works on Linux, but not on Windows seems like a very serious issue with Windows support. I know that this is work in progress and that VS 2015 broke the ABI of its CRT, and it's hard to track down those problems with every VS release, so let me know if I can help with anything. Currently I do not have enough knowledge tackle the problem, but I am willing to learn.
Oct 14 2015
next sibling parent reply Szymon Gatner <noemail gmail.com> writes:
On Wednesday, 14 October 2015 at 11:46:27 UTC, ZombineDev wrote:

 2) How can I workaround the problem that _minfo* and _deh* are 
 not generated because my main is in C++?
Just add a file with int main() in D library to fix this.
Oct 14 2015
parent ZombineDev <valid_email he.re> writes:
On Wednesday, 14 October 2015 at 11:54:22 UTC, Szymon Gatner 
wrote:
 On Wednesday, 14 October 2015 at 11:46:27 UTC, ZombineDev wrote:

 2) How can I workaround the problem that _minfo* and _deh* are 
 not generated because my main is in C++?
Just add a file with int main() in D library to fix this.
Thanks! I didn't realize that I could add an empty main in D and force the linker to use the C++ main just by ordering the arguments to the linker :D For 32-bit under VS2015 x86 Native Tools Command Prompt: dmd -lib -m32mscoff my_d_lib.d cl main.cpp my_d_lib.lib C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib" And for 64-bit under VS2015 x64 Native Tools Command Prompt: dmd -lib -m64 my_d_lib.d cl main.cpp my_d_lib.lib C:\D\dmd2\windows\lib64\phobos64.lib "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64\legacy_stdio_definitions.lib" Both works for me. Anyway, I still don't think that forcing the users to use this workaround is a great idea.
Oct 14 2015
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 14.10.2015 13:46, ZombineDev wrote:
 On Tuesday, 13 October 2015 at 20:10:22 UTC, Rainer Schuetze wrote:
 Yes, but there is some magic involved when linking against the VS2015
 CRT. To use symbols like snprintf and sscanf, you must also pass
 legacy_stdio_definitions.lib to the linker, which is done
 automatically if you use dmd as a frontend to the linker, but not cl.

 Symbols _minfo_beg, _minfo_end, _deh_beg and _deh_end are only emitted
 by the compiler if you compile main, WinMain or DllMain.
 Unfortunately, compiling D's main also generates a C-style main, so
 it's not so easy to get these symbols if you need main in C/C++.

 I would currently recommend to write main in D, and call into C/C++
 from there.
Thanks for the answer. Just for the reference, under VS2015 x86 Native Tools Command Prompt I tried to link a C++ main function that only calls rt_init() and rt_term() like this: cl main.cpp C:\D\dmd2\windows\lib32mscoff\phobos32mscoff.lib "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib" I got: main.cpp phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_beg referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo phobos32mscoff.lib(sections_win64_6de_5a5.obj) : error LNK2019: unresolved external symbol __minfo_end referenced in function _D2rt14sections_win6414getModuleInfosFZAyPS6object10ModuleInfo main.exe : fatal error LNK1120: 2 unresolved externals Which, based on your answer, is expected. I'm looking into integrating D into an existing C++ build and I need to statically link the D library. So my next questions are: 1) Where can I find legacy_stdio_definitions.lib? P.S.: It's included in VS (C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\legacy_stdio_definitions.lib)
Your C++ project should have the library paths setup correctly to find it if you just add it to the additional input libraries.
 2) How can I workaround the problem that _minfo* and _deh* are not
 generated because my main is in C++?
As Szymon noticed, you can compile an empty main into the static D library. The additional C main that is generated by DMD won't cause ambiguities as long as your C main is not also in a static library.
Oct 14 2015
parent ZombineDev <valid_email he.re> writes:
On Wednesday, 14 October 2015 at 12:39:46 UTC, Rainer Schuetze 
wrote:
 As Szymon noticed, you can compile an empty main into the 
 static D library. The additional C main that is generated by 
 DMD won't cause ambiguities as long as your C main is not also 
 in a static library.
Thanks for the advice (I just found that myself). Why this workaround is not needed on Linux?
Oct 14 2015