Re: Beta D 2.069.0-b1

[Steven Schveighoffer via Digitalmars-d-announce]

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?). 
 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

Re: Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

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;

Re: Beta D 2.069.0-b1

[Szymon Gatner via Digitalmars-d-announce]

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


_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

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Szymon Gatner via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Szymon Gatner via Digitalmars-d-announce]

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\Bravo\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?

Re: Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

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:

Error2error 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.

Re: Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Szymon Gatner via Digitalmars-d-announce]

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\Bravo\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

Re: Beta D 2.069.0-b1

[ZombineDev via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Szymon Gatner via Digitalmars-d-announce]

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 
#include 

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();

  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.

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Kagamin via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Kagamin via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Rainer Schuetze via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[ZombineDev via Digitalmars-d-announce]

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?

Re: Beta D 2.069.0-b1

[John Colvin via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

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 :)

Re: Beta D 2.069.0-b1

[Johannes Pfau via Digitalmars-d-announce]

Am Sun, 11 Oct 2015 01:54:39 +
schrieb deadalnix :

> 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.

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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)) -> _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/

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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;

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

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!";

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Iain Buclaw via Digitalmars-d-announce]

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
>
> foo() # calling function
>
> a = -> { }
> a.call # calling lambda
> a.() # alternative syntax for calling lambda
>
> 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
>
>   def foo=(a) # not the same name as "foo"
>   end
> end
>
> a = Foo.new
> a.bar = 3 # error
> a.foo = 3 # ok
> a.foo(3) # error
>
>
It seems to be a misfeature of D to accept the equivalent of all three of
those examples as valid.

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Jonathan M Davis via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[deadalnix via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Jacob Carlborg via Digitalmars-d-announce]

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

foo() # calling function

a = -> { }
a.call # calling lambda
a.() # alternative syntax for calling lambda

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

  def foo=(a) # not the same name as "foo"
  end
end

a = Foo.new
a.bar = 3 # error
a.foo = 3 # ok
a.foo(3) # error

--
/Jacob Carlborg

Re: Beta D 2.069.0-b1

[John Colvin via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Andrea Fontana via Digitalmars-d-announce]

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?

Re: Beta D 2.069.0-b1

[Joakim via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Adam D. Ruppe via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Adam D. Ruppe via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Jonathan M Davis via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Meta via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Ola Fosheim Grøstad via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Andrea Fontana via Digitalmars-d-announce]

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 :)

Re: Beta D 2.069.0-b1

[extrawurst via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[lobo via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Andrea Fontana via Digitalmars-d-announce]

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...

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

On Thursday, 8 October 2015 at 04:53:53 UTC, Suliman wrote:

Is it DDMD based release?


Yes.

Re: Beta D 2.069.0-b1

[Andrea Fontana via Digitalmars-d-announce]

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."

Re: Beta D 2.069.0-b1

[Tourist via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Ilya Yaroshenko via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Andrea Fontana via Digitalmars-d-announce]

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?

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Per Nordlöw via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Adam D. Ruppe via Digitalmars-d-announce]

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).

Re: Beta D 2.069.0-b1

[Jack Stouffer via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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).

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[David Nadlinger via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[anonymous via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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()?

Re: Beta D 2.069.0-b1

[anonymous via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[ponce via Digitalmars-d-announce]

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?

Re: Beta D 2.069.0-b1

[ponce via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Nick Sabalausky via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[Steven Schveighoffer via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Jack Stouffer via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[NVolcz via Digitalmars-d-announce]

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?

Beta D 2.069.0-b1

[Martin Nowak via Digitalmars-d-announce]

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

Re: Beta D 2.069.0-b1

[Suliman via Digitalmars-d-announce]

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?

Re: Beta D 2.069.0-b1

[drug via Digitalmars-d-announce]

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.

Re: Beta D 2.069.0-b1

[extrawurst via Digitalmars-d-announce]

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