Hi!
Good to see D is progressing! I was active forum and bugzilla
participant in 2011-2013. Since then I have not touched D.
What is the progress of D (2014-2017) in following dimensions:
1) Support of linking in win64? AFAIK Walter introduced win64
support in circa 2012 which was the big pro
On Tuesday, 22 September 2015 at 17:43:59 UTC, Maxim Fomin wrote:
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
Sure, but in many cases D allows you to work around decisions
you don't like. Plus, you can actively contribute, make
suggestions and prove your case. The length of so
On Tuesday, 22 September 2015 at 13:38:33 UTC, Chris wrote:
On Tuesday, 22 September 2015 at 11:44:35 UTC, Maxim Fomin
wrote:
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
to be confined by committee decisions etc.,
D has committee (Walter & Andrei). Some of their decisions
fr
On Tuesday, 22 September 2015 at 11:01:28 UTC, Chris wrote:
to be confined by committee decisions etc.,
D has committee (Walter & Andrei). Some of their decisions
frustrate D users too.
On Tuesday, 22 September 2015 at 06:03:25 UTC, Laeeth Isharc
wrote:
On Monday, 21 September 2015 at 19:15:28 UTC, Maxim Fomin wrote:
OK, the frustration is understandable. D is good enough to
impress in short-run but has problems damaging itself in the
long run. This leads to impression -> fru
On Sunday, 20 September 2015 at 17:32:53 UTC, Adam wrote:
My experiences with D recently have not been fun.
...
My main concern with .NET is portability and performance. I am
going to give in to the portability and just assume Mono is
good enough. Performance wise, I'd prefer D, but .NET is
pe
On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote:
After leaving C++ behind for a few years to work in some
higher-level languages for job-related coding, I was excited
when I stumbled upon D ...
This is a typical path ...
I spent several weeks tearing through the language reference
an
On Wednesday, 13 May 2015 at 18:59:42 UTC, Dennis Ritchie wrote:
Hi,
I think that many will find something interesting in this
article:
-
https://translate.google.ru/translate?hl=ru&sl=ru&tl=en&u=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F257875%2F
-
Sorry translated using google translate.
C
On Wednesday, 13 May 2015 at 09:20:36 UTC, Bienlein wrote:
"You are making a cool project and we'd like to contribute to
it, but we don't know and neither feel like studying this silly
D".
This is indeed a problem for many newly created languages.
Scala has somewhat managed to create its own
On Thursday, 9 April 2015 at 09:53:15 UTC, John Colvin wrote:
struct BigLongStructName
{
int evenLongerMemberName;
}
struct QN{}
unittest
{
BigLongStructName bigLongStructName;
@(bigLongStructName.evenLongerMemberName)
QN quickName;
__tr
On Sunday, 16 November 2014 at 13:39:24 UTC, FrankLike wrote:
Many old projects need move from x86 to x64,but the 'length'
type is size_t,it will change on x64,so a lot of work must to
do.but I find some info which is help for d:
http://www.dotnetperls.com/array-length.
it means:
test length
Currently I am building dmd on win64. For some reason some phobos
code references getErrno() function in errno_c.obj and that
object file is not included into final binary (linker issues
symbol absence error - by the way I don't remember it was needed
on linux). It can be avoided by adding file
On Wednesday, 18 June 2014 at 05:34:18 UTC, Sebastian Unger wrote:
So again, I believe, if D wants to play any role in major OO
software design and development, it will need to step up its
game. Especially in view of C++11 having addressed a number of
the issues in C++ that I would have chose
On Tuesday, 17 June 2014 at 15:15:44 UTC, Luís Marques wrote:
Is there any particular reason why this is accepted? (I
introduced it by mistake):
void foo(int = 3) {}
I guess it could be useful to ensure binary compatibility when
you expect to add the parameter later?
Actually there is no
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
(C) int function(char[][])*).runAll().void __lambda1()
0x0040
On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Schütz wrote:
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
void main()
{
asm { int 3; }
}
object.Error: Breakpoint
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern
On Wednesday, 11 June 2014 at 16:50:30 UTC, Walter Bright wrote:
On 6/11/2014 4:34 AM, Timon Gehr wrote:
Not memory safe implies (is supposed to imply) not @safe but
not @safe does not
imply not memory safe.
@safe in D == memory safe.
Why? I found dozens of cases when @safe is broken, let a
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an
object to exist that violates it without
On Saturday, 14 June 2014 at 17:05:21 UTC, David Nadlinger wrote:
On Saturday, 14 June 2014 at 16:45:19 UTC, Maxim Fomin wrote:
The case which you described is a not a type safety problem.
If a struct type has a non-trivial invariant(), .init allows an
object to exist that violates it without
On Saturday, 14 June 2014 at 15:41:10 UTC, John Colvin wrote:
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Wh
On Saturday, 14 June 2014 at 14:51:10 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 13:38:40 UTC, Maxim Fomin wrote:
Which is effectively a type system hole with @disable this :
struct A { @disable this(); }
auto a = A.init;
Why this is a type hole if initializer is explicitly provided?
T
On Saturday, 14 June 2014 at 12:33:28 UTC, Dicebot wrote:
On Saturday, 14 June 2014 at 10:15:49 UTC, Marc Schütz wrote:
Huh? Types with `@disable this()` still have an `init` value.
All it does is disallow instantiating the type without
specifying an initializer (e.g. a struct literal, a value
22 matches
Mail list logo
