[Issue 14437] Double scope(failure) ignored

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14437

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |INVALID

--- Comment #1 from b2.t...@gmx.com ---
The code that should reproduce the bug is now invalid and doesn't compile

--

[Issue 13790] Spellchecker doesn't work for enum members

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13790

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

[Issue 13238] getMember trait changes function linkage

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13238

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

Re: Best memory management D idioms

[ag0aep6g via Digitalmars-d-learn]

On 03/08/2017 02:15 AM, XavierAP wrote:

I see the default allocator is the same GC heap used by 'new'. Just for
my learning curiosity, does this mean that if I theAllocator.make()
something and then forget to dispose() it, it will be garbage collected
the same once no longer referenced? And so are these objects traversed
by the GC?


Yes and yes. GCAllocator.allocate calls core.memory.GC.malloc with does 
pretty much the same thing as the builtin `new`.


One difference might be with preciseness. `new` can take the type into 
account and automatically mark the allocation as NO_SCAN. I'm not sure 
if GCAllocator can do that. Maybe if you use `make`/`makeArray` to make 
the allocations.



I've also looked at mallocator, [2] can it be used in some way to
provide an allocator instead of the default theAllocator? As far as I
can tell mallocator is not enough to implement an IAllocator, is there a
reason, or where's the rest, am I missing it?


To make an IAllocator, use std.experimental.allocator.allocatorObject. 
The example in the documentation shows how it's done.


https://dlang.org/phobos/std_experimental_allocator.html#.allocatorObject

Re: DMD + Dynamic Library.

[Jerry via Digitalmars-d-learn]

You have to use "export" for any symbol to be visible from a dll. 
On Windows by default nothing is exported.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[thedeemon via Digitalmars-d]

On Tuesday, 7 March 2017 at 19:09:11 UTC, bachmeier wrote:

Yep. If you want to give someone enough rope to get maximum 
performance, you have to give them enough rope to shoot 
themselves in the foot. Once you've moved into this territory, 
you've made a decision to throw away safety and convenience in 
the name of performance, and you better understand what you're 
doing.


I think ATS language is a contradiction here, it combines max 
performance (at some point it was #1 at the PL shootout, faster 
than C) with static guarantees Rust folks could only dream about. 
But the price you pay is amount of intellectual efforts (and 
time, a lot of time!) to write any non-trivial program.

DMD + Dynamic Library.

[Damien Gibson via Digitalmars-d-learn]

Hi everyone. My first post here - I'm not one to usually resort 
to trying to ask forums directly for help but I'm a bit desperate 
at this point as I have wasted about 3 days in total of no-life 
googling trying to figure something out here.


My current setup works fine for creation of EXE's and Static 
libs. Dynamic libs are the only problem. I have some libraries I 
created and used just fine with static libs that I'd like to 
start using dynamically as managing them with multiple projects 
has just become too cumbersome.


My setup uses Mono-D using -shared and -H(-shared should already 
be called as it already generated .lib and .dll files but I added 
again just in case) and creating a new EXE project and trying to 
use the functions from the generated .di files works fine -> As 
long as the lib was generated static. While attempting to use 
dynamic generated .lib I always get the error "Library Reference 
Missing".


On each of my source files I've attempted adding export 
extern(D): right after Module declaration(Which again works just 
fine when using static edition of .lib) as well as I've used this 
for the dllmain (Which has only been modified slightly from the 
ones in guides)


version(Windows) {
import core.sys.windows.windows : HINSTANCE;
	extern(Windows)	bool DllMain(HINSTANCE hInstance, uint ulReason, 
void* reserved) {

import core.sys.windows.dll, core.sys.windows.windows;
switch(ulReason) {
default: assert(0);
			case DLL_PROCESS_ATTACH: return dll_process_attach( hInstance, 
true );
			case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true 
);	return true;

case DLL_THREAD_ATTACH: return dll_thread_attach( true, 
true );
case DLL_THREAD_DETACH: return dll_thread_detach( true, 
true );
}
}
}


I've compiled EVERYTHING into x32 for windows and this being of 
course with the latest dmd2 compiler.


I'm all out of ideas here. From some of the threads I've come 
across researching the .def files that were in the main guides 
aren't needed as long as using the export extern(D): however 
whether or not they are actually needed or not -> Either the 
compiler or linker were throwing errors(I cant remember which).


I've even tried running .def made for example modules as well and 
it gave the same error so i know i wasn't just making it 
improperly.


I'm literally a couple tests from pulling my hair out so any 
wisdom on this issue would be greatly appreciated!

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Soulsbane via Digitalmars-d]

On Tuesday, 7 March 2017 at 20:47:12 UTC, Ali Çehreli wrote:

On 03/07/2017 11:33 AM, Soulsbane wrote:

What does he mean by sidetracked by social causes? I've seen 
this

mentioned before. Is this a big thing in the Rust community?


The author had opened the following thread:

  
http://forum.dlang.org/post/dvmsnoxvdbmraisoc...@forum.dlang.org


  "community seems infused with both the Feminism/SJW"

Ali


Ah, thanks for the link Ali!

Re: DUB specify version identifier on command line?

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 22:30:30 UTC, XavierAP wrote:
I'm talking about the conditional compilation keyword 
"version", not about version strings. I've looked in DUB's help 
and reference [1][2] but can't seem to find how to solve my 
problem. On the command line it seems to be possible to specify 
debug identifiers, but not version identifiers. [3]


It came up while trying to do something specific, so I'll 
explain this. I'm learning and trying things, and I was playing 
with dlib.core.memory. Before moving to the next thing I wanted 
to try printMemoryLog(). This outputs memory debugging info, 
only when compiled with version(MemoryDebug) [3].


I'm working with Visual D. However for 3rd party package 
dependencies it's simpler to compile them with dub, and have VS 
find the lib for my client project. Without the version 
identifier, my program works: compiles, links to dlib, and runs 
ok. Then I instruct VS to define version(MemoryDebug) for some 
configuration. No matter how I re-run dub to build dlib, I get 
linking errors from the additional functions defined in the 
imported dlib source which aren't found in the binary lib.


I guess it's also possible to specify this by adding to the 
dub.json file [2], but for me it's more flexible if I can leave 
it alone and compile different versions from the command line 
alone. But if the json is the only way please let me know. 
Otherwise what am I missing? Thanks in advance.



[1] http://code.dlang.org/docs/commandline#build
[2] http://code.dlang.org/package-format?lang=json#version-specs
[3] https://dlang.org/spec/version.html#DebugCondition
[4] 
https://github.com/gecko0307/dlib/blob/master/dlib/core/memory.d


Setting version identifiers is done by the `-version=ident` 
command line flag (this is equivalent to `version = ident` at 
source level) .
This should therefore be settable by the "dflags" dub 
configuration setting.


The way I would do it would be to have a custom configuration 
that sets "dflags" : [ "other normal flags", "-version= 
MemoryDebug"]


and then build the MemoryDebug dub configuration.

Hope that makes sense.

Re: Best memory management D idioms

[XavierAP via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use 
allocators. You can use "make" and "dispose" from 
std.experimental.allocator the same way as New/Delete.


OK I've been reading on std.experimental.allocator; it looks 
really powerful and general, more than I need. I see the 
potential but I don't really have the knowledge to tweak memory 
management, and the details of the "building blocks" are well 
beyond me.


But even if I don't go there, I guess it's a good thing that I 
can change my program's allocator by changing one single line or 
version assigning theAllocator, and benchmark the results among 
different possibilities.


I see the default allocator is the same GC heap used by 'new'. 
Just for my learning curiosity, does this mean that if I 
theAllocator.make() something and then forget to dispose() it, it 
will be garbage collected the same once no longer referenced? And 
so are these objects traversed by the GC?


I've also looked at mallocator, [2] can it be used in some way to 
provide an allocator instead of the default theAllocator? As far 
as I can tell mallocator is not enough to implement an 
IAllocator, is there a reason, or where's the rest, am I missing 
it?



[1] https://dlang.org/phobos/std_experimental_allocator.html
[2] 
https://dlang.org/phobos/std_experimental_allocator_mallocator.html

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 March 2017 at 20:44:26 UTC, Nick Sabalausky 
(Abscissa) wrote:
I found it horribly scary at first myself, but what surprised 
me is that in all the years I've used D, I've never hit an 
problem resulting from that, not even once.


Just wait till you use a library that added a sentinel at the end 
of it temporarily...

[Issue 17215] [Reg 2.073] ICE(cgcod.c:findreg) with SIMD and -O -inline

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17215

--- Comment #8 from github-bugzi...@puremagic.com ---
Commit pushed to revert-6566-fix17215 at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/4373a211ed16d05650aeb1779881b12e09c2ca80
Revert "fix Issue 17215 -  ICE(cgcod.c:findreg) with SIMD and -O -inline"

--

Re: DMD Refuses to Compile Multiple Source Files

[Samwise via Digitalmars-d-learn]

On Wednesday, 18 January 2017 at 04:25:42 UTC, Mike Parker wrote:


extern(C), not simply extern. It turns off the name mangling. 
But really, the proper thing to do is to drop the prototype and 
import the module with the implementation. It's tge way modules 
are intended to be used. Unless you're doing something specidic 
like writing a library that calls an arbitrary user function.


Alright, so I misunderstood what ketmar was saying. His solution 
did work. I'm just not sure I understand what you are trying to 
say here:


I've started using dub for things, and I've learned a lot since 
this thread. Anyway, thanks for the support with this everybody.

Re: Date formatting in D

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, March 07, 2017 22:15:39 Daniel Kozak via Digitalmars-d-learn 
wrote:
> I do not know? Is this some ISO/ANSI format for dates? If yes than we
> should add it. If no there is no reason.

The ISO formats are already there. There's to/fromISOString and
to/fromISOExtString on SysTime, DateTime, Date, and TimeOfDay. What's
missing is custom date/time formatting, and it's on my todo list, but I've
had enough other stuff going on that I haven't gotten around to it even
though I should have done it ages ago.

- Jonathan M Davis

Re: Problems with setting up dub for publication

[Samwise via Digitalmars-d-learn]

On Sunday, 5 March 2017 at 01:54:22 UTC, Mike Parker wrote:

...


I was getting the same problem and created on issue on this 
project's repository 
(https://github.com/ZILtoid1991/pixelperfectengine), which I 
think (although I don't know) was the reason this thread was 
created. Using the dub.json that I added in that PR will compile. 
However, since I didn't actually write any code, I doubt that if 
I imported anything from pixelperfect that it would still work. 
This is an issue I saw somewhere else...


Anyway, building "pixelperfectengine:pixelperfectengine": "*" 
works with the hello world app.d, although like I said, probably 
will not if I try to import anything from pixelperfect. Building 
"pixelperfectengine": "~>0.9.1-rc2" does not work, it still gives 
me the linker error from the top of this thread.


I like dub too. It has worked well for me and seems to be much 
lighter and less of a mess than at least some IDE's. Right now I 
finished fixing the d-struct package for the atom text editor, 
which adds dub support for that, so I don't have to use the 
command line hardly at all :P. In any case, dub is a great tool, 
and works well most of the time.

Re: Phobos and LTO

[kinke via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:46:15 UTC, Johan Engelen wrote:

On Tuesday, 7 March 2017 at 18:42:40 UTC, Johan Engelen wrote:


It works on OS X too.
And OS X is the only platform for which we package the LTO 
linker binaries in the release.


Has anybody tried LLD on Windows for D already?
https://lld.llvm.org/windows_support.html

If LLD works (or another linker that can use the LLVM plugin), 
then LTO is also available on Windows.


-Johan


Yep, I gave LLD 3.9 a try on Win64 some weeks ago. Works out of 
the box as drop-in replacement for Microsoft's link.exe, incl. 
usage of environment variables. What's apparently still lacking 
is debuginfos (.pdb) generation, so our CDB debugging tests 
failed (all others worked IIRC).
LLD is supposed to be significantly faster than Microsoft's 
linker; I haven't done any measurements yet. Besides offering 
nice stuff like LTO, integrating LLD should allow LDC to directly 
cross-compile *and* cross-link. So you'll only need the target 
system libs to produce objects, libraries and executables for 
'any' target. Which is pretty awesome.

DUB specify version identifier on command line?

[XavierAP via Digitalmars-d-learn]

I'm talking about the conditional compilation keyword "version", 
not about version strings. I've looked in DUB's help and 
reference [1][2] but can't seem to find how to solve my problem. 
On the command line it seems to be possible to specify debug 
identifiers, but not version identifiers. [3]


It came up while trying to do something specific, so I'll explain 
this. I'm learning and trying things, and I was playing with 
dlib.core.memory. Before moving to the next thing I wanted to try 
printMemoryLog(). This outputs memory debugging info, only when 
compiled with version(MemoryDebug) [3].


I'm working with Visual D. However for 3rd party package 
dependencies it's simpler to compile them with dub, and have VS 
find the lib for my client project. Without the version 
identifier, my program works: compiles, links to dlib, and runs 
ok. Then I instruct VS to define version(MemoryDebug) for some 
configuration. No matter how I re-run dub to build dlib, I get 
linking errors from the additional functions defined in the 
imported dlib source which aren't found in the binary lib.


I guess it's also possible to specify this by adding to the 
dub.json file [2], but for me it's more flexible if I can leave 
it alone and compile different versions from the command line 
alone. But if the json is the only way please let me know. 
Otherwise what am I missing? Thanks in advance.



[1] http://code.dlang.org/docs/commandline#build
[2] http://code.dlang.org/package-format?lang=json#version-specs
[3] https://dlang.org/spec/version.html#DebugCondition
[4] 
https://github.com/gecko0307/dlib/blob/master/dlib/core/memory.d

Re: If you needed any more evidence that memory safety is the future...

[XavierAP via Digitalmars-d]

On Tuesday, 7 March 2017 at 21:24:43 UTC, Moritz Maxeiner wrote:
Then we need to define "memory safe language" a lot stricter 
than it's currently being used, and both D and Rust won't 
qualify as memory safe (since you can write unsafe code in 
them).


D does not claim to be memory-safe always. It does afaik do so 
within @safe environments (barring internal runtime or compiler 
bugs of course). Even C# has the same approach of allowing 
"unsafe" environments.


A formal, mathematical proof is impossible, yes, but if you 
have a large enough sample size of programs in a memory 
safe(r) language, *and* can verify that they are indeed 
memory correct (and thus not open to all the usual attack 
vectors), then that falls what I'd categorize under "hard to 
refute". But you're right, I should've been more specific, my 
bad.


Does anybody try to refute it? Safe languages are not rejected 
for their safety.


Right now, of course not, since the burden of proof is on the 
side advocating memory safety (i.e. us).


I don't agree on the burden of proof. It is a safe assumption 
that if you increase safety checks, safety will be improved. It 
cannot or needn't be proven. If someone proposes installing 
railing in a stairway, or a fence along a railway, to decrease 
accidents, who would demand this to be proven? How, in a sandbox 
parallel universe that we control as gods and can rewind in time? 
Because there is no other way.


Plus statistics can prove nothing -- this logical truth cannot be 
overstated. Even if you invested for the sake of an experiment in 
setting up a race between huge teams of equally qualified 
programmers given the same exact tasks, nothing could be truly 
proven. But we're even talking about simply having more 
experience from completely different projects and developers 
among the evaluated languages or families. Actually we have quite 
a lot of experience already, by now Java and later .NET have been 
around for most of the time C++ has so far, just as an for 
example.

Re: [OT] Why don't you advertise more your language on Quora etc ?

[H. S. Teoh via Digitalmars-d]

On Mon, Mar 06, 2017 at 10:41:06PM -0500, Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:
[...]
> Yes, this. Although, granted, the OO-koolaid *was* quite strong indeed
> in those days.
> 
> It really is strange to look back on all that, when I was fairly sold
> on OO too (just not quite as fanatically so), and compare to now:
> 
> At this point I feel that class-based polymorphism mostly just turned
> out to be an awkward work-around for the lack of first-class functions
> and closures in mainstream languages. What convinced me: After years
> of using D, I find myself using OO less and less (OO polymorphism
> nearly never, aside from exception hierarchies), and instead of
> feeling hamstringed I feel liberated - and I'm normally a kitchen-sink
> kinda guy!

I was never fully "sold" to the OO bandwagon, though I did appreciate
the different way of looking at a programming problem.  While I found OO
to be a nice way of structuring a program that deals with
highly-structured data (it was like abstract data types on steroids), I
never really understood the folks who see it as the be-all and end-all
and want to essentially recast all of computer science in OO terms.

Like you, after coming to terms with D's duck-typing range idioms I've
started moving away from OO and leaning more in the direction of generic
programming via templates. These days I even prefer static polymorphism
via structs and alias this, than full-out classes.  Of course, classes
still do have their place when runtime polymorphism is needed, and I do
use that at times. But it occupies a far smaller percentage of my code
than the OO advocates would rally for.


T

-- 
Do not reason with the unreasonable; you lose by definition.

Re: Passing macros from commandline or enumerating versions

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

The way I like to do it is to pass a module on the command line 
that contains the custom config. So in the app:


---
import myapp.config;

// use the variables defined in there like normal
---


Now, to define a config file, you do something like:


myconfiguration.d # note that the file name can be anything!
---
module myapp.config; // but each must use this same module config

enum some_key = "some_value";
// and so on
---

Now, when you compile, you build it with a particular config by 
passing one of those files to the compile:


dmd myapp.d myconfiguration.d # or whatever single config you want



Then you can define as much as you want in the config module, and 
have as many of them as you want too.

[Issue 17245] Errors about expressions with no effect only are given for basic types

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17245

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
   Severity|normal  |enhancement

--

Re: Zcoin implementation bug enabled attacker to create 548,000 Zcoins

[Walter Bright via Digitalmars-d]

On 3/7/2017 9:45 AM, Atila Neves wrote:

1 warning generated.


Pretty much all C++ compilers will generate warnings for this. The thing about 
warnings, though, is they imply that there are situations where the code is 
acceptable. I can't think of any. It needs to be an error. It should never pass 
the compiler.




Does D do better?


Yes, it's an error in D.

Passing macros from commandline or enumerating versions

[Martin Drašar via Digitalmars-d-learn]

Hi,

I was wondering, if there is a way to pass a macro with value to the
compiled program, i.e., something like -Dfoo="bar". And if that is not
possible, if there is a way to enumerate all set versions.

I want my application built with different string imported
configurations and I have no idea how to tell compiler which
configuration to choose, other than hardcoding it.

Thanks,
Martin

Re: Date formatting in D

[Daniel Kozak via Digitalmars-d-learn]

Dne 7.3.2017 v 21:29 aberba via Digitalmars-d-learn napsal(a):

I've been trying to figure out an inbuilt functionality in phobos for 
formatting date. In my use case, I've been trying to format current 
Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of strings 
is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been resolved? 
What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com
Sorry for my previous comments. I have not been reading this post 
carefully. AFAIK you want some universal (general) format method for 
dates. This make sense. So if you write pull request I believe it will 
be accepted.

Re: If you needed any more evidence that memory safety is the future...

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 7 March 2017 at 16:18:01 UTC, Kagamin wrote:

On Friday, 3 March 2017 at 17:33:14 UTC, Moritz Maxeiner wrote:
And you can write memory incorrect programs in what's 
currently called memory safe languages[1]


Those look like mistakes in interfacing between C and Rust. So 
it's not really written in a safe language. And most of them 
are in cryptographic security rather than memory safety. Safe 
languages give no advantage there. But it still does 
demonstrate lack of safety issues.


Then we need to define "memory safe language" a lot stricter than 
it's currently being used, and both D and Rust won't qualify as 
memory safe (since you can write unsafe code in them).




A formal, mathematical proof is impossible, yes, but if you 
have a large enough sample size of programs in a memory 
safe(r) language, *and* can verify that they are indeed memory 
correct (and thus not open to all the usual attack vectors), 
then that falls what I'd categorize under "hard to refute". 
But you're right, I should've been more specific, my bad.


Does anybody try to refute it? Safe languages are not rejected 
for their safety.


Right now, of course not, since the burden of proof is on the 
side advocating memory safety (i.e. us).

Re: Date formatting in D

[Daniel Kozak via Digitalmars-d-learn]

Dne 7.3.2017 v 22:07 aberba via Digitalmars-d-learn napsal(a):


On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote:
I've been trying to figure out an inbuilt functionality in phobos for 
formatting date. In my use case, I've been trying to format current 
Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of strings 
is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been 
resolved? What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com


Just found this http://code.dlang.org/packages/datetimeformat.

Why is Phobos not still not having this in 2017?


I have looked at some of our many years old codebase and we use
http://dlang.org/phobos/std_format.html#.formattedRead

and

http://dlang.org/phobos/std_format.html#.formattedWrite

Re: Phobos and LTO

[Daniel Kozak via Digitalmars-d]

Dne 7.3.2017 v 19:42 Johan Engelen via Digitalmars-d napsal(a):


On Tuesday, 7 March 2017 at 18:15:52 UTC, Temtaime wrote:

On Sunday, 5 March 2017 at 19:52:12 UTC, Daniel Kozak wrote:

Dne 5.3.2017 v 20:31 Temtaime via Digitalmars-d napsal(a):


On Sunday, 5 March 2017 at 17:17:13 UTC, Las wrote:

Is Phobos compiled with LTO enabled?


There is no LTO with D.

Yes it is
https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html 



Being specific only for LDC and only on linux - it's a lie to say 
simple « yes ».


Cheer up, you wrote "there is no LTO with D", which there clearly is. :-)

It works on OS X too.
And OS X is the only platform for which we package the LTO linker 
binaries in the release.


-Johan


OTOH he maybe has dmd in mind when he speaking about D. It is a really 
common pattern (problem) I am challenging every time (unfortunately) 
when I am speaking about D.

Re: Date formatting in D

[Daniel Kozak via Digitalmars-d-learn]

I do not know? Is this some ISO/ANSI format for dates? If yes than we 
should add it. If no there is no reason.



Dne 7.3.2017 v 22:07 aberba via Digitalmars-d-learn napsal(a):

On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote:
I've been trying to figure out an inbuilt functionality in phobos for 
formatting date. In my use case, I've been trying to format current 
Unix timestamp to something like "Thu, 08 Mar 2017 12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of strings 
is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been 
resolved? What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com


Just found this http://code.dlang.org/packages/datetimeformat.

Why is Phobos not still not having this in 2017?

Re: Ordering comparisons

[Andrei Alexandrescu via Digitalmars-d]

On 03/07/2017 03:49 PM, H. S. Teoh via Digitalmars-d wrote:

Unfortunately, because strings are arrays, deprecating array comparisons
*will* break a *lot* of code.


Misunderstanding, string comparisons are legit because character 
comparisons are legit. This is about deprecating array comparisons that 
don't have a corresponding element comparison. -- Andrei

Re: Date formatting in D

[aberba via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote:
I've been trying to figure out an inbuilt functionality in 
phobos for formatting date. In my use case, I've been trying to 
format current Unix timestamp to something like "Thu, 08 Mar 
2017 12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of 
strings is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been 
resolved? What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com


Just found this http://code.dlang.org/packages/datetimeformat.

Why is Phobos not still not having this in 2017?

Re: Ordering comparisons

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 07, 2017 at 07:53:37PM +, Stefan Koch via Digitalmars-d wrote:
> On Tuesday, 7 March 2017 at 19:40:53 UTC, Andrei Alexandrescu wrote:
> > On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:
> > > (1) I may be remembering wrong, but I thought structs had always
> > > been intended to be compared field-wise?  I remember when working
> > > on AA's that the compiler would emit a default implementation of
> > > opEquals that did member-wise comparisons. I had always assumed
> > > that something similar was done with inequalities... or was that
> > > just unfounded extrapolation?
> > 
> > We currently do memcmp.
> > 
> > Equality by memberwise comparison is almost always meaningful;
> > ordering by lexicographic comparison of members is not.
> > 
> > 
> > Andrei
> 
> We should deprecate that array comparison behavior immediately.  It
> should not break much code, otherwise the issue would have popped up
> before.

Unfortunately, because strings are arrays, deprecating array comparisons
*will* break a *lot* of code.

I'm all for deprecating comparisons between arrays of structs, though.
The best way to do this is to deprecate implicit struct comparisons (the
user has to define opCmp if he wants to compare structs).


T

-- 
What doesn't kill me makes me stranger.

[Issue 17232] The index page for std.algorithm looks bad on mobile

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17232

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/bc7d20a638d4c14feb7b2b12a44d35078a140530
Issue 17232 - make std.algorithm table more digestable

https://github.com/dlang/phobos/commit/1bcba2a9937eb35d7d968663e5c5f6f237d1d182
Merge pull request #5213 from wilzbach/make-std-algorithm-table-more-digestable

Issue 17232 - make std.algorithm table more digestable

--

Re: Date formatting in D

[ikod via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 20:29:07 UTC, aberba wrote:
I've been trying to figure out an inbuilt functionality in 
phobos for formatting date. In my use case, I've been trying to 
format current Unix timestamp to something like "Thu, 08 Mar 
2017 12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of 
strings is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been 
resolved? What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com


Straightforward solution:

https://dlang.org/library/core/stdc/time/strftime.html
http://man7.org/linux/man-pages/man3/strftime.3.html

Maybe there is something better.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Ali Çehreli via Digitalmars-d]

On 03/07/2017 11:33 AM, Soulsbane wrote:


What does he mean by sidetracked by social causes? I've seen this
mentioned before. Is this a big thing in the Rust community?


The author had opened the following thread:

  http://forum.dlang.org/post/dvmsnoxvdbmraisoc...@forum.dlang.org

  "community seems infused with both the Feminism/SJW"

Ali

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/07/2017 12:52 PM, Ola Fosheim Grøstad wrote:

On Tuesday, 7 March 2017 at 12:53:42 UTC, bachmeier wrote:

D's arrays are sane, consistent, and logically intuitive even
accounting for the "determinism issue". I've never understood why this
behavior is surprising - it's exactly what I'd expect. But then I
don't program in a way that it's relevant, so maybe I don't understand
how it matters.


It is horrible. It is something you only would expect from a hacky
scripting language. No ifs or buts.


I found it horribly scary at first myself, but what surprised me is that 
in all the years I've used D, I've never hit an problem resulting from 
that, not even once.


I admit I can't even begin to explain *why* it's never turned out to be 
a problem for me though. (And now, *that* is the part that bothers me a 
little.)


Filed, in my brain at least, under "Strange but True".

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:49:15 UTC, Guillaume Piolat wrote:
On Tuesday, 7 March 2017 at 18:19:47 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 7 March 2017 at 17:59:28 UTC, Meta wrote:
What exactly are we talking about here? The array stomping 
protection stuff?


Lack of static guarantees on the underlying array buffer.


Like with pointers, ownership doesn't have to be encoded in the 
type this way.


One can always work around misguided high level features with 
abstractions, but it doesn't scale well when features that lead 
to inconsistency is part of the core language. But in comparison 
to Go one does at least have the ability to abstract.


I still find it odd that people downplay the value of static 
guarantees in the core language. I am likewise puzzled by the 
dynamic choices in Golang, but to their credit they decided to 
focus on evolving the runtime.


I think Rust made a lot of the right choices, except they didn't 
go far enough to fully reap the benefits.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/07/2017 02:07 PM, Jack Stouffer wrote:


I've seen this mentioned serval times now by people coming from Rust.

Rust users: Is the PC/politicking really that pervasive in their community?


That surprised me too. My impression is that us D community folks 
chastise ourselves plenty for conversations constantly veering off the 
technical path! Was a pleasant surprise to read a new user say "nah, 
that's really not so bad in D". Who know? :)

Re: Best memory management D idioms

[Eugene Wissner via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 20:15:37 UTC, XavierAP wrote:

On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use 
allocators. You can use "make" and "dispose" from 
std.experimental.allocator the same way as New/Delete.


Thanks! looking into it.

Does std.experimental.allocator have a leak debugging tool like 
dlib's printMemoryLog()?


Yes, but printMemoryLog is anyway useful only for simple 
searching for memory leaks. For the advanced debugging it is 
anyway better to learn some memory debugger or profiler.

Re: Independent Study at my university using D

[Random D user via Digitalmars-d-announce]

On Monday, 6 March 2017 at 02:25:41 UTC, Jeremy DeHaan wrote:
The precise GC is going to continue to hang until it can be 
tweaked to be as fast or faster than the conservative GC we 
have now.


In which cases?
Shouldn't this be pulled and put behind a switch? I thought D's 
GC was supposed to be pluggable.


This way people could actually try to use it easily and provide 
valuable real-world feedback and use cases. With some luck we 
could even get someone to contribute/improve the GC (at least for 
their use cases).


It doesn't have to be the default. It doesn't have to be perfect 
to be released as experimental.


I would probably try it if I could enable it with a simple 
compiler/application switch, but I'm not going to pull and build 
it from the source.


Sounds to me like current situation actively blocks people from 
contributing instead of encouraging them.

Date formatting in D

[aberba via Digitalmars-d-learn]

I've been trying to figure out an inbuilt functionality in phobos 
for formatting date. In my use case, I've been trying to format 
current Unix timestamp to something like "Thu, 08 Mar 2017 
12:00:00 GMT".


How do I go by this easily (Currently, long concatenation of 
strings is what I'm thinking)?


I saw this thread[1] from 2011 on similar issue. Has it been 
resolved? What is the state of toCustomString?


[1] 
http://forum.dlang.org/post/mailman.673.1320367887.24802.digitalmars-d-le...@puremagic.com

Re: Of the use of unpredictableSeed

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/07/2017 05:18 AM, Seb wrote:


As apparently no one here hasn't mentioned this, Linux >= 3.17 has a
dedicated syscall API. Please see:

http://man7.org/linux/man-pages/man2/getrandom.2.html

And this excellent introductory article:

https://lwn.net/Articles/605828



Ooh, that's great to know! (Kinda sad that it seems necessary, given the 
"unix filesystem and unix design" ideals, but oh well, realities are 
realities.)


Is there a "proper" way to check for this function's existence on a 
local machine, other than test-compiling, or is parsing 'uname -a' as 
"right way" as it gets?


And anyone know about OSX? Would OSX use the getentropy the article you 
linked to mentions for OpenBSD? Or something else? Or just fallback to 
/dev/(u)random?


This really deserves a Phobos PR, IMO, FWIW. Maybe I'll try my hand at 
it if any OSX folk have tips for that OS.

Re: Best memory management D idioms

[XavierAP via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 18:21:43 UTC, Eugene Wissner wrote:
To avoid this from the beginning, it may be better to use 
allocators. You can use "make" and "dispose" from 
std.experimental.allocator the same way as New/Delete.


Thanks! looking into it.

Does std.experimental.allocator have a leak debugging tool like 
dlib's printMemoryLog()?

Re: Of the use of unpredictableSeed

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 03/07/2017 09:46 AM, Kagamin wrote:

On Tuesday, 7 March 2017 at 10:18:52 UTC, Seb wrote:

http://man7.org/linux/man-pages/man2/getrandom.2.html



Unnecessarily reading large quantities of data will have a negative
impact on other users of the /dev/random and /dev/urandom devices.
Therefore, getrandom() should not be used for Monte Carlo simulations
or other programs/algorithms which are doing probabilistic sampling.


In other words it shouldn't be used when not strictly necessary.


Yes, although that's true of reading /dev/(u)random too. (Just to be clear.)

Re: Ordering comparisons

[Stefan Koch via Digitalmars-d]

On Tuesday, 7 March 2017 at 19:40:53 UTC, Andrei Alexandrescu 
wrote:

On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:
(1) I may be remembering wrong, but I thought structs had 
always been
intended to be compared field-wise?  I remember when working 
on AA's
that the compiler would emit a default implementation of 
opEquals that
did member-wise comparisons. I had always assumed that 
something
similar was done with inequalities... or was that just 
unfounded

extrapolation?


We currently do memcmp.

Equality by memberwise comparison is almost always meaningful; 
ordering by lexicographic comparison of members is not.



Andrei


We should deprecate that array comparison behavior immediately.
It should not break much code, otherwise the issue would have 
popped up before.

Re: Ordering comparisons

[Andrei Alexandrescu via Digitalmars-d]

On 03/07/2017 12:54 PM, H. S. Teoh via Digitalmars-d wrote:

(1) I may be remembering wrong, but I thought structs had always been
intended to be compared field-wise?  I remember when working on AA's
that the compiler would emit a default implementation of opEquals that
did member-wise comparisons. I had always assumed that something
similar was done with inequalities... or was that just unfounded
extrapolation?


We currently do memcmp.

Equality by memberwise comparison is almost always meaningful; ordering 
by lexicographic comparison of members is not.



Andrei

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Soulsbane via Digitalmars-d]

On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:

https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/


Very welcoming and helpful community that actually focuses on the 
technical side of things rather than getting sidetracked by 
social causes


What does he mean by sidetracked by social causes? I've seen this 
mentioned before. Is this a big thing in the Rust community?

removing module level from ddox output

[Bryce via Digitalmars-d-learn]

Is there a way to flatten out the documentation hierarchy 
generated by ddox? To be more clear, when we generate 
documentation with dub -b ddox, the main page lists all my 
modules, and each module page lists all the classes in that 
module, etc. I want to remove the modules from the main page and 
just list my classes as if they were in a single module without 
having to put everything in a single file.


We can already do this from a code point of view by publicly 
importing stuff in package.d, so from the user's perspective 
there is only a single module with some classes in it (they don't 
have to worry about how I organized things in various files). Is 
there a way to make the documentation match this simple import 
paradigm?


I suspect it's possible by redefining some ddoc macros in 
package.d, but I'm not quite sure how to go about it or if 
there's and easier way.


Thanks!

Re: [OT] Re: Why don't you advertise more your language on Quora etc ?

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 07, 2017 at 06:45:55PM +, Rico Decho via Digitalmars-d wrote:
[...]
> But I don't think that D's GC is fine for people who care about it.
> 
> If it is, why are people on this forum giving advices on how to
> disable and/or avoid it for soft real-time applications where a GC
> freeze can't be tolerated.
> 
> D's GC isn't a crap at all, but better designs and implementations
> exist, and Nim's GC is one of them.
> 
> We can either learn from it, or ignore it... But the second solution
> won't make D more appropriate for soft real-time scenarios...

What the D GC needs is somebody willing to sit down and actually spend
the time to improve/rewrite the code.  Over the years there has been an
endless stream of fancy ideas, feature requests, and wishlists for the
GC, but without anybody actually doing the work, nothing will actually
happen.  We are all very well aware of the current GC's limitations and
flaws for years now, and there has been some amount of improvements
going into it over the years.  But again, talking about it won't
magically make it better.  *Somebody* has to write the code, after all.

If anyone is interested to help, take a look at:

https://github.com/dlang/druntime/pull/1603

and review the code, give some feedback, run the benchmarks yourself,
etc., to prod this PR along.

If you have other ideas for improving the GC (e.g., adapting ideas from
Nim's GC), submitting PRs to that effect would be much more effective
than merely talking about it.


T

-- 
If you want to solve a problem, you need to address its root cause, not just 
its symptoms. Otherwise it's like treating cancer with Tylenol...

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[bachmeier via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:06:05 UTC, H. S. Teoh wrote:

Like bachmeier, I have found D arrays (well, slices) to be 
exactly how I expect arrays to work. The "determinism issue" is 
really only a problem in exceptional cases where you probably 
should be using a custom type instead. Or in cases where you're 
worried about performance and therefore have to understand the 
nitty-gritty of exactly how slices work in all possible cases 
-- something that you already have to learn in the first place, 
if performance is a concern.  I love D arrays, warts and all.


Yep. If you want to give someone enough rope to get maximum 
performance, you have to give them enough rope to shoot 
themselves in the foot. Once you've moved into this territory, 
you've made a decision to throw away safety and convenience in 
the name of performance, and you better understand what you're 
doing.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Jack Stouffer via Digitalmars-d]

On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:

https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/


This reenforces my estimation that the most persuasive feature of 
any language is the ability to get shit done. That's not a 
positive value judgement on that focus however. The argument 
probably should side on the ability to make safe/correct programs 
_while also_ creating them quickly.



Very welcoming and helpful community that actually focuses
on the technical side of things rather than getting sidetracked 
by social causes


I've seen this mentioned serval times now by people coming from 
Rust.


Rust users: Is the PC/politicking really that pervasive in their 
community?

Re: Deterministic Memory Management With Standard Library Progress

[Guillaume Piolat via Digitalmars-d]

On Monday, 6 March 2017 at 16:10:51 UTC, Anthony wrote:
This is also encouraging! Thanks for the concrete advice. But, 
I think due to my inexperience, to don't really understand some 
of your advice. Specifically, the only-memory recourses like 
strings and arrays can be managed by the GC, and arena pools. I 
can just look these things up, but I figured it'd be easy to 
ask first.


(Arena pools are an allocator type, unrelated to your question 
(though they are used to lessen GC usage) ).



When I speak about "only-memory" resources I mean resources that 
only hold memory transitively.



class MyClass
{
string a;
ubyte[] arr;
float p;
}

There is not much reason to destroy - or release the memory of - 
a MyClass deterministically since it only references memory. A 
global owner like the GC will do.


In C++ you would find an owner for each std::string, but in D you 
can rely on the GC for releaseing them.


But you shalt not rely on the GC for closing files, releasing 
mutexes, closing sockets... etc. Any object that would hold such 
a resource (or holds an object that holds such a resource) is 
better handled in a manual/RAII way instead. Memory allocated 
with malloc is such a resource too.


In my mind, D programs use a hybrid style of ownership, GC + 
manual/RAII(aka "scoped ownership"). So it's more complex that 
just "scoped ownership" like in C++.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Guillaume Piolat via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:19:47 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 7 March 2017 at 17:59:28 UTC, Meta wrote:
What exactly are we talking about here? The array stomping 
protection stuff?


Lack of static guarantees on the underlying array buffer.


Like with pointers, ownership doesn't have to be encoded in the 
type this way.

Re: Phobos and LTO

[Johan Engelen via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:42:40 UTC, Johan Engelen wrote:


It works on OS X too.
And OS X is the only platform for which we package the LTO 
linker binaries in the release.


Has anybody tried LLD on Windows for D already?
https://lld.llvm.org/windows_support.html

If LLD works (or another linker that can use the LLVM plugin), 
then LTO is also available on Windows.


-Johan

Re: [OT] Re: Why don't you advertise more your language on Quora etc ?

[Rico Decho via Digitalmars-d]

D seems to be in a situation where those who don't care have a 
crap GC which needs to be improved and those who do care have 
the tools to deal with it. So there needs to be ongoing 
replacement of the D GC until there is something good, this is 
a technical problem. That people who care about the effect of 
GC still think D is a crap GC-based language implies there is a 
marketing problem, not a technical one.


But I don't think that D's GC is fine for people who care about 
it.


If it is, why are people on this forum giving advices on how to 
disable and/or avoid it for soft real-time applications where a 
GC freeze can't be tolerated.


D's GC isn't a crap at all, but better designs and 
implementations exist, and Nim's GC is one of them.


We can either learn from it, or ignore it... But the second 
solution won't make D more appropriate for soft real-time 
scenarios...

Re: Phobos and LTO

[Johan Engelen via Digitalmars-d]

On Tuesday, 7 March 2017 at 18:15:52 UTC, Temtaime wrote:

On Sunday, 5 March 2017 at 19:52:12 UTC, Daniel Kozak wrote:

Dne 5.3.2017 v 20:31 Temtaime via Digitalmars-d napsal(a):


On Sunday, 5 March 2017 at 17:17:13 UTC, Las wrote:

Is Phobos compiled with LTO enabled?


There is no LTO with D.

Yes it is
https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html


Being specific only for LDC and only on linux - it's a lie to 
say simple « yes ».


Cheer up, you wrote "there is no LTO with D", which there clearly 
is. :-)


It works on OS X too.
And OS X is the only platform for which we package the LTO linker 
binaries in the release.


-Johan

Re: D street cred: Just a thought

[ketmar via Digitalmars-d]

Ilya Yaroshenko wrote:


I don't care about existing D users.


i wonder if "existing D users" care about your "betterC" and other 
initiatives then.


rethorical sentence, no need to answer to it.

Re: Best memory management D idioms

[Eugene Wissner via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 17:37:43 UTC, XavierAP wrote:

On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote:

There's nothing like that of C++.


Don't you think New/Delete from dlib.core.memory fills the 
bill? for C++ style manual dynamic memory management? It looks 
quite nice to me, being no more than a simple malloc wrapper 
with constructor/destructor calling and type safety. Plus 
printMemoryLog() for debugging, much easier than valgrind.


do you want to manage non-memory resources with these memory 
management mechanisms too?


I wasn't thinking about this now, but I'm sure the need will 
come up.


Yes. For simple memory management New/Delete would be enough. But 
you depend on your libc in this case, that is mostly not a 
problem. From experience it wasn't enough for some code bases, so 
the C-world invented some work arounds:


1) Link to an another libc providing a different malloc/free 
implementations
2) Use macros that default to the libc's malloc/free, but can be 
set at compile time to an alternative implementation (mbedtls 
uses for example mbedtls_malloc, mbedtls_calloc and mbedtls_free 
macros)


To avoid this from the beginning, it may be better to use 
allocators. You can use "make" and "dispose" from 
std.experimental.allocator the same way as New/Delete.


I tried to introduce the allocators in dlib but it failed, 
because dlib is difficult to modify because of other projects 
based on it (although to be honest it was mostly a communication 
problem as it often happens), so I started a similar lib from 
scratch.

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 March 2017 at 17:59:28 UTC, Meta wrote:
What exactly are we talking about here? The array stomping 
protection stuff?


Lack of static guarantees on the underlying array buffer.

Re: Phobos and LTO

[Temtaime via Digitalmars-d]

On Sunday, 5 March 2017 at 19:52:12 UTC, Daniel Kozak wrote:

Dne 5.3.2017 v 20:31 Temtaime via Digitalmars-d napsal(a):


On Sunday, 5 March 2017 at 17:17:13 UTC, Las wrote:

Is Phobos compiled with LTO enabled?


There is no LTO with D.

Yes it is
https://johanengelen.github.io/ldc/2016/11/10/Link-Time-Optimization-LDC.html


Being specific only for LDC and only on linux - it's a lie to say 
simple « yes ».

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[H. S. Teoh via Digitalmars-d]

On Tue, Mar 07, 2017 at 05:52:23PM +, Ola Fosheim Grøstad via Digitalmars-d 
wrote:
> On Tuesday, 7 March 2017 at 12:53:42 UTC, bachmeier wrote:
> > D's arrays are sane, consistent, and logically intuitive even
> > accounting for the "determinism issue". I've never understood why
> > this behavior is surprising - it's exactly what I'd expect. But then
> > I don't program in a way that it's relevant, so maybe I don't
> > understand how it matters.
> 
> It is horrible. It is something you only would expect from a hacky
> scripting language. No ifs or buts.

That's an opinion.

Like bachmeier, I have found D arrays (well, slices) to be exactly how I
expect arrays to work. The "determinism issue" is really only a problem
in exceptional cases where you probably should be using a custom type
instead. Or in cases where you're worried about performance and
therefore have to understand the nitty-gritty of exactly how slices work
in all possible cases -- something that you already have to learn in the
first place, if performance is a concern.  I love D arrays, warts and
all.


T

-- 
"The whole problem with the world is that fools and fanatics are always so 
certain of themselves, but wiser people so full of doubts." -- Bertrand 
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

[Issue 17245] Errors about expressions with no effect only are given for basic types

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17245

--- Comment #1 from Jack Stouffer  ---
This should also apply to opCmp, and opBinaryRight

--

Re: Ordering comparisons

[H. S. Teoh via Digitalmars-d]

On Mon, Mar 06, 2017 at 08:27:56PM -0500, Andrei Alexandrescu via Digitalmars-d 
wrote:
> While reviewing work on array comparisons, Vladimir found an odd issue:
> 
> https://issues.dlang.org/show_bug.cgi?id=17244
> 
> Investigation reveals that during array comparison for inequality,
> structs are compared by means of memcmp - even if they don't define
> opCmp, and regardless of the types of their fields. This has obvious
> unpleasant consequences:

Couple of points:

(1) I may be remembering wrong, but I thought structs had always been
intended to be compared field-wise?  I remember when working on AA's
that the compiler would emit a default implementation of opEquals that
did member-wise comparisons. I had always assumed that something
similar was done with inequalities... or was that just unfounded
extrapolation?

(2) I didn't realize that arrays allowed inequalities by default, though
in retrospect it does make sense (since we do define string
inequalities, and string are arrays).  But I would have expected that
structs would *not* allow inequalities by default, because it's not
clear that a default ordering relation makes sense for every struct.
Consider for example, a struct representation of a complex number:

struct Complex { float re, im; }

It would be wrong to assume a default ordering relation on this struct
because the complex numbers do not have a linear ordering.


[...]
> The question is what to do to minimize breakage yet "break the bad
> code".  The most backward-compatible solution is to define opCmp
> automatically to do a field-by-field lexicographical comparison. The
> most radical solution is disable ordering comparisons unless
> explicitly implemented by the user.
[...]

I wouldn't say disabling ordering comparisons is "radical".  In fact, I
think it makes the most sense by assuming the least about the user's
intended semantics for the struct.  Lexicographical ordering by default
makes sense for arrays (e.g., strings), but I don't think it makes sense
for general structs. Without the user stating what his intents are, it
seems unfounded to presume lexicographic ordering by default.  If the
user has a struct of orthogonal information, e.g., name, phone number,
address, there is no reason why changing the order of fields (during
code refactoring, for example) should result in a completely different
ordering just because the language assumes lexicographical ordering by
default.  It's better to make it an error to involve structs in
inequalities if the user didn't explicitly define opCmp, than to
silently accept such comparisons, which are likely to be buggy, and then
have unusual behaviour later when the user reorders fields and a
seemingly unrelated part of the code suddenly begins producing different
output.

I'd say allowing inequalities on structs by default is surprising
behaviour, whereas asking the user to explicitly specify an ordering is
more expected.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- 
Christopher

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Meta via Digitalmars-d]

On Tuesday, 7 March 2017 at 17:52:23 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 7 March 2017 at 12:53:42 UTC, bachmeier wrote:
D's arrays are sane, consistent, and logically intuitive even 
accounting for the "determinism issue". I've never understood 
why this behavior is surprising - it's exactly what I'd 
expect. But then I don't program in a way that it's relevant, 
so maybe I don't understand how it matters.


It is horrible. It is something you only would expect from a 
hacky scripting language. No ifs or buts.


What exactly are we talking about here? The array stomping 
protection stuff?

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 March 2017 at 12:53:42 UTC, bachmeier wrote:
D's arrays are sane, consistent, and logically intuitive even 
accounting for the "determinism issue". I've never understood 
why this behavior is surprising - it's exactly what I'd expect. 
But then I don't program in a way that it's relevant, so maybe 
I don't understand how it matters.


It is horrible. It is something you only would expect from a 
hacky scripting language. No ifs or buts.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[Atila Neves via Digitalmars-d]

On Tuesday, 7 March 2017 at 06:59:38 UTC, Walter Bright wrote:

On 3/6/2017 10:06 PM, Jack Stouffer wrote:
To be fair, this also would have been caught with proper 
testing ... which

obviously didn't happen.


My idea of fair is it should never have gotten past the 
compiler. It's a simple mistake for the compiler to detect.


clang 3.9.1 with 0 flags used:

$ cat zcoin.cpp
int main() {
int a, b;
a == b;
}
$ clang++ zcoin.cpp

zcoin.cpp:3:7: warning: equality comparison result unused 
[-Wunused-comparison]

a == b;
~~^~~~
zcoin.cpp:3:7: note: use '=' to turn this equality comparison 
into an assignment

a == b;
  ^~
  =
1 warning generated.

gcc, sadly, warns about nothing by default but does with `-Wall`. 
But... anyone not using `-Wall -Wextra -Werror` on a new C++ 
codebase shouldn't be writing C++ AFAIC*. And then there's the 
aforementioned lack of adequate testing.


Does D do better? Sort of (clang issues a warning, which I know 
can be and is often ignored). Is this an example of amateur hour 
by the Zcoin devs? Indubitably.


Atila

* Maybe there should be something like a driver's license for C++ 
where devs have to pass a test before they're allowed to write 
code. Something like "Do you know how to use std::enable_if 
without looking at cppreference.com? No? Fail." (I'd fail, I 
_always_ have to look up how to use enable_if. Then again, it 
_is_ a horrible hacky hack of a hack based on the hack that is 
SNIFAE).

Re: Best memory management D idioms

[XavierAP via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 16:51:23 UTC, Kagamin wrote:

There's nothing like that of C++.


Don't you think New/Delete from dlib.core.memory fills the bill? 
for C++ style manual dynamic memory management? It looks quite 
nice to me, being no more than a simple malloc wrapper with 
constructor/destructor calling and type safety. Plus 
printMemoryLog() for debugging, much easier than valgrind.


do you want to manage non-memory resources with these memory 
management mechanisms too?


I wasn't thinking about this now, but I'm sure the need will come 
up.

Re: WebAssembly design is done?

[Ola Fosheim Grøstad via Digitalmars-d]

This looks like a nice tool for those wanting to learn more about 
WebAssembly:


https://mbebenita.github.io/WasmExplorer/

Re: If you needed any more evidence that memory safety is the future...

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 March 2017 at 15:48:12 UTC, Kagamin wrote:

On Monday, 6 March 2017 at 21:05:13 UTC, Timon Gehr wrote:
Not every program with a wrong assertion in it exceeds array 
bounds.


Until it does.


Going outside array bounds isn't necessarily the same as a 
contradiction.

Re: Best memory management D idioms

[Kagamin via Digitalmars-d-learn]

On Sunday, 5 March 2017 at 20:54:06 UTC, XavierAP wrote:
What I want to learn (not debate) is the currently available 
types, idioms etc. whenever one wants deterministic memory 
management.


There's nothing like that of C++. Currently you have Unique, 
RefCounted, scoped and individual people efforts on this. BTW, do 
you want to manage non-memory resources with these memory 
management mechanisms too?

Re: [OT] Re: Why don't you advertise more your language on Quora etc ?

[Russel Winder via Digitalmars-d]

On Mon, 2017-03-06 at 10:22 -0800, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> Nevertheless, it's certainly true that D's GC could use a major
> upgrade
> at some point.  While it's not horrible, the present implementation
> does
> leave more to be desired.  Hopefully the various efforts at GC by
> forum
> members will at some point turn into some major improvements to D's
> GC.
> There was talk a year or two ago about a precise for D (with fallback
> to
> conservative GC for cases where that wouldn't work), but I'm not sure
> what has come of it.
[…]

Learn the lesson from Java. It started with a truly crap GC and
everyone said Java is crap because the GC is garbage. D has seemingly
actually progressed beyond this stage technically but not marketing
wise. The Java folk worked on the GC and kept replacing it over and
over again. The GC got better and better. Now with the G1 GC almost all
the problem have gone away – as has most of the moaning about Java
having a crap GC. Most people never notice the GC and those that do,
engineer it rather than moaning. The Java GC situation is now a
sophisticated one where those who don't really care do not have a
problem and those that do care have the tools to deal with it.

D seems to be in a situation where those who don't care have a crap GC
which needs to be improved and those who do care have the tools to deal
with it. So there needs to be ongoing replacement of the D GC until
there is something good, this is a technical problem. That people who
care about the effect of GC still think D is a crap GC-based language
implies there is a marketing problem, not a technical one.

We all know that many, many people see the word garbage collector and
run a mile in an uneducated prejudiced way. Who cares about them. We
care about the people who are willing to try stuff out and have a
problem.



-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc
Description: This is a digitally signed message part

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[Wyatt via Digitalmars-d]

On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:

https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/


I like the bit in the comments where he says this:

"It doesn’t have to be idiomatic to work just fine, which is 
relaxing."


People often don't get how nice this is.

-Wyatt

Re: If you needed any more evidence that memory safety is the future...

[Kagamin via Digitalmars-d]

On Friday, 3 March 2017 at 17:33:14 UTC, Moritz Maxeiner wrote:
And you can write memory incorrect programs in what's currently 
called memory safe languages[1]


Those look like mistakes in interfacing between C and Rust. So 
it's not really written in a safe language. And most of them are 
in cryptographic security rather than memory safety. Safe 
languages give no advantage there. But it still does demonstrate 
lack of safety issues.


A formal, mathematical proof is impossible, yes, but if you 
have a large enough sample size of programs in a memory safe(r) 
language, *and* can verify that they are indeed memory correct 
(and thus not open to all the usual attack vectors), then that 
falls what I'd categorize under "hard to refute". But you're 
right, I should've been more specific, my bad.


Does anybody try to refute it? Safe languages are not rejected 
for their safety.

Re: Cconditional expression in return statement. Bug?

[kinke via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 14:26:18 UTC, Jack Applegame wrote:
I'm pretty sure this is a bug. And very bad bug. I spent 
several hours looking for it.

What do you think?


Definitely a very bad bug. It works too if you mark `fun()` as 
nothrow. Please file a DMD issue.

Re: If you needed any more evidence that memory safety is the future...

[Kagamin via Digitalmars-d]

On Monday, 6 March 2017 at 21:05:13 UTC, Timon Gehr wrote:
Not every program with a wrong assertion in it exceeds array 
bounds.


Until it does.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[ketmar via Digitalmars-d]

Jack Stouffer wrote:


On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:

only for primitive types, sadly.

void main () {
Object a, b;
a == b;
}

oops. no more error messages. yes, i know that this invokes 
`opEquals()`, and `opEquals()` can have side-effects. but what are the 
chances of writing such code *intentionally*?


Hmm, I guess the compiler can (and should) output an error message if it 
knows that opEquals is `pure`.


https://issues.dlang.org/show_bug.cgi?id=17245


yet Object's `opEquals()` is not pure (and it cannot be, to allow non-pure 
overloads). still, the code i've written has no sense.

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[ketmar via Digitalmars-d]

Walter Bright wrote:


https://makebitcoingreatagain.wordpress.com/2017/02/18/is-the-zcoin-bug-in-checktransaction/#update6

The error is here:

https://github.com/zcoinofficial/zcoin/blob/81a667867b5d8489...

and the line of code:

zccoinSpend.denomination == libzerocoin::ZQ_LOVELACE;

In other words, a statement with no effect. In D, such a line gives an 
error, not a warning:


Error: == has no effect in expression


only for primitive types, sadly.

 void main () {
   Object a, b;
   a == b;
 }

oops. no more error messages. yes, i know that this invokes `opEquals()`, 
and `opEquals()` can have side-effects. but what are the chances of writing 
such code *intentionally*?


i guess, compiler should emit error for *any* usage of "==" without using 
the result, even if it lowers to `opEquals()` or something. and if one 
really want to use it and drop it's result, there is always escape path:


 cast(void)(a == b);

Re: Zcoin implementation bug enabled attacker to create 548, 000 Zcoins

[Jack Stouffer via Digitalmars-d]

On Tuesday, 7 March 2017 at 15:05:45 UTC, ketmar wrote:

only for primitive types, sadly.

 void main () {
   Object a, b;
   a == b;
 }

oops. no more error messages. yes, i know that this invokes 
`opEquals()`, and `opEquals()` can have side-effects. but what 
are the chances of writing such code *intentionally*?


Hmm, I guess the compiler can (and should) output an error 
message if it knows that opEquals is `pure`.


https://issues.dlang.org/show_bug.cgi?id=17245

[Issue 17245] New: Errors about expressions with no effect only are given for basic types

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17245

  Issue ID: 17245
   Summary: Errors about expressions with no effect only are given
for basic types
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

Example

void main () {
Object a, b;
a == b;
}

gives no error.

The problem lies, as ketmar put it, with opEquals

> oops. no more error messages. yes, i know that this invokes 
> `opEquals()`, and `opEquals()` can have side-effects. but what 
> are the chances of writing such code *intentionally*?

Here, the compiler can be helpful by outputing an error if the used opEquals is
marked as pure. There's no way that a pure opEquals should be used in an
expression with no effect.

--

Re: Of the use of unpredictableSeed

[Kagamin via Digitalmars-d]

On Tuesday, 7 March 2017 at 10:18:52 UTC, Seb wrote:

http://man7.org/linux/man-pages/man2/getrandom.2.html


Unnecessarily reading large quantities of data will have a 
negative impact on other users of the /dev/random and 
/dev/urandom devices.  Therefore, getrandom() should not be used 
for Monte Carlo simulations or other programs/algorithms which 
are doing probabilistic sampling.


In other words it shouldn't be used when not strictly necessary.

Cconditional expression in return statement. Bug?

[Jack Applegame via Digitalmars-d-learn]

Code (https://dpaste.dzfl.pl/8e7a9c380e99):

import std.stdio;
struct Foo {
int val;
this(int val) {
writefln("%s.this(int)", val);
this.val = val;
}
this(this) {
writefln("%s.this(this)", val);
this.val = val;
}
~this() {
writefln("%s.~this()", val);
this.val = val;
}
}
struct Bar {
Foo foo;
this(Foo foo, bool) { this.foo = foo; }
}

bool fun(bool val) { return !val; }

auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), fun(!flag));
}

void main(string[] args) {
auto bar = genBar(args.length == 0);
}

Compiler generates extra destructor call:

10.this(int)
10.this(this)
10.~this()
10.~this()
10.~this()

If we slightly change function genBar:
auto genBar(bool flag) {
auto a = flag ? Bar() : Bar(Foo(10), fun(!flag));
return a;
}

or

auto genBar(bool flag) {
return flag ? Bar() : Bar(Foo(10), false);
}

then output looks as expected:

10.this(int)
10.this(this)
10.~this()
10.~this()

I'm pretty sure this is a bug. And very bad bug. I spent several 
hours looking for it.

What do you think?

Re: Ordering comparisons

[Dominikus Dittes Scherkl via Digitalmars-d]

On Tuesday, 7 March 2017 at 02:51:37 UTC, Jonathan M Davis wrote:

If we can, we should probably make structs that have opCmp use 
opCmp like they should, and those that don't continue to use 
memcmp for the moment but get a deprecation message. Then after 
whatever amount of time we think is appropriate, we disable the 
comparisons. So, we don't break anything immediately, but 
ultimately end up with the correct situation of comparisons not 
working unless opCmp being defined.

+1
This is the only sensible approach.

Re: Ordering comparisons

[Andrei Alexandrescu via Digitalmars-d]

On 03/06/2017 10:44 PM, Nick Sabalausky (Abscissa) wrote:

On 03/06/2017 08:27 PM, Andrei Alexandrescu wrote:


* A struct S { int x; } compares differently on little endian and big
endian system (!)



This one is very surprising. How is that so, if both structs being
compared are of the same endian-ness?


On a big endian system, comparing integers with memcmp works correctly 
because higher-rank bytes are compared before lower-rank bytes. On a 
little endian system, lower-rank bytes are compared first, which would 
make e.g. 256 less than 1. Porting code that relies on comparing arrays 
of structs for ordering is likely to be a nightmare. We really need to 
fix this. -- Andrei

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[bachmeier via Digitalmars-d]

On Tuesday, 7 March 2017 at 09:54:36 UTC, qznc wrote:

I somewhat wonder about "Arrays (arguably the most important 
data structure) are actually sane, consistent, and very much 
logically intuitive in D unlike the mess that’s C (and C++)." 
At some points, people get bitten by the determinism issue [0]. 
Probably, z0ltan was lucky so far. Nevertheless, arrays/slices 
are the way they are for good reasons.


[0] https://dlang.org/d-array-article.html


D's arrays are sane, consistent, and logically intuitive even 
accounting for the "determinism issue". I've never understood why 
this behavior is surprising - it's exactly what I'd expect. But 
then I don't program in a way that it's relevant, so maybe I 
don't understand how it matters.

Re: Ordering comparisons

[deadalnix via Digitalmars-d]

On Tuesday, 7 March 2017 at 01:27:56 UTC, Andrei Alexandrescu 
wrote:
The question is what to do to minimize breakage yet "break the 
bad code". The most backward-compatible solution is to define 
opCmp automatically to do a field-by-field lexicographical 
comparison. The most radical solution is disable ordering 
comparisons unless explicitly implemented by the user.




There should be no assumption that structs are comparable, so the 
later.

Can i using D & LLVM & SDL2 for Android?

[dummy via Digitalmars-d-learn]

Just thought. I do want to know. :-)

As far as I know is,
  * LDC2 woring on NDK(yah!)
  * Native OpenGLES: 
http://wiki.dlang.org/Build_LDC_for_Android#Build_a_sample_OpenGL_Android_app_ported_to_D
  * Dlangui working on Android that based on SDL2: 
https://github.com/buggins/dlangui / 
https://dlang.org/blog/2016/10/07/project-highlight-dlangui/


regards,

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[XavierAP via Digitalmars-d]

On Tuesday, 7 March 2017 at 09:54:36 UTC, qznc wrote:
I somewhat wonder about "Arrays (arguably the most important 
data structure) are actually sane, consistent, and very much 
logically intuitive in D unlike the mess that’s C (and C++)." 
At some points, people get bitten by the determinism issue


On the contrary, he does mention D's safety and memory management 
different from Rust, C and C++ as a good point for him actually.


Every thread ends up in the same discussion :p and is GC really 
so bad in all and every case?

Re: How to compile against GitHub fork of Phobos?

[XavierAP via Digitalmars-d-learn]

On Tuesday, 7 March 2017 at 01:14:28 UTC, Q. Schroll wrote:

I have a fork of the standard-library in the folder "phobos".


DMD looking for the built-in phobos is specified in the 
configuration file (sc.ini on Windows, dmd.conf on Linux), not 
hardcoded. You may want to remove it from there. When you specify 
-I on top of this, I guess the compiler looks in both places in 
some order.


You could also clone your modified Phobos to the directory built 
into the DMD distribution. But maybe you want to have both. You 
may also keep and use two DMD bin folders, with different 
configuration files. There are many possibilities for you to 
configure what you want.


Also yes with your configuration I think you should remove the 
preceding "phobos." from imports, since you're already telling 
the compiler to look inside the phobos folder.

[Issue 13855] Allow multiple selective imports from different modules in a single import statement

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=13855

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
> Much better signal/noise ratio.

That's clearly a matter of opinion, as I find the multi-line import much more
legible.

--

Re: Of the use of unpredictableSeed

[Seb via Digitalmars-d]

On Tuesday, 7 March 2017 at 03:43:42 UTC, Jonathan M Davis wrote:
On Monday, March 06, 2017 22:04:44 Nick Sabalausky  via 
Digitalmars-d wrote:

On 03/06/2017 05:19 PM, sarn wrote:
> On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh 
> wrote:
>> Excuse me if I'm asking a trivial question. Why not just 
>> seed it from /dev/urandom? (or equivalent on non-Linux 
>> platforms. I know at least Windows has an equivalent).

>>
>> Shachar
>
> One reason is that /dev/urandom isn't always available, 
> e.g., in a chroot.  Sure, these are corner cases, but it's 
> annoying when stuff like this doesn't "just work".


I don't claim to be any sort of linux expert or anything, but 
doesn't chroot have a reputation for being a bit of a finicky, 
leaky abstraction anyway? I haven't really used them, but 
that's been my understanding...?


If you want a fully secure chroot, then what you really want is 
BSD jails or Solaris zones. chroots are indeed too leaky to be 
secure. But secure container-ization doesn't really matter 
here, since a D program using D's standard number generator 
should work regardless of where it's running. So, it's a 
question of whether we're guaranteed to get at /dev/urandom or 
not, and if not, how reasonable it is to require that it be 
accessible for the program to run. There _are_ programs that 
require access to /dev, and /dev is _usually_ available.


Regardless, if there is no guarantee that /dev/urandom (or 
whatever system resource for getting randomness is) is going to 
be accessible, and we want to use it, then we either have to 
require that it be accessible and error out if it isn't, or we 
have to have a backup if accessing it fails. Ideally, you'd be 
able to just use /dev/urandom and not worry about it, but I 
don't know how common it is for /dev/urandom to be unavailable 
or how reasonable it is to require that it be available.


In general though, using /dev/urandom to seed the pseudo-random 
number generator seems like a good plan.


- Jonathan M Davis


As apparently no one here hasn't mentioned this, Linux >= 3.17 
has a dedicated syscall API. Please see:


http://man7.org/linux/man-pages/man2/getrandom.2.html

And this excellent introductory article:

https://lwn.net/Articles/605828

I did work on getting a nice getEntropy function into mir-random:

https://github.com/libmir/mir-random/pull/13

(For which it was planned to backport it to Phobos after some 
testing and real-world  feedback on the API.)

Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D

[qznc via Digitalmars-d]

On Tuesday, 7 March 2017 at 03:04:05 UTC, Joakim wrote:

https://z0ltan.wordpress.com/2017/02/21/goodbye-rust-and-hello-d/


"A much much safer language than C++ while being much more 
programmer-friendly than Rust."


Nice quote. :)

I somewhat wonder about "Arrays (arguably the most important data 
structure) are actually sane, consistent, and very much logically 
intuitive in D unlike the mess that’s C (and C++)." At some 
points, people get bitten by the determinism issue [0]. Probably, 
z0ltan was lucky so far. Nevertheless, arrays/slices are the way 
they are for good reasons.


[0] https://dlang.org/d-array-article.html

[Issue 14245] Immutable reference to immutable field in constructor allows breaking type system

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14245

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com

--- Comment #2 from Eduard Staniloiu  ---
Adding another example of this issue.

immutable(int)* g;

struct X {
int a = 10;
immutable this(int x) {
g = 
a = 42;
}
}

void main() {
auto x = immutable X();
}

This is problematic in multithreaded environments since the global variable `g`
is shared among threads which rely on it's immutability to provide concurrent,
lock free, accesses.

--

Re: Ordering comparisons

[Jacob Carlborg via Digitalmars-d]

On 2017-03-07 04:44, Nick Sabalausky (Abscissa) wrote:


This one is very surprising. How is that so, if both structs being
compared are of the same endian-ness?


The structs for a given run will be of the same endian-ness. But if you 
run the same code on two different systems, one with little endian and 
one with big endian, you will get different results when sorting an 
array, for example. If I understand this correctly.


--
/Jacob Carlborg