[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

  Component|dmd |phobos

--- Comment #4 from Mike Franklin  ---
According to digger this Phobos commit caused the regression.

digger: 082e53c2fb5c28179bef45554d1b2157ffc4fdc8 is the first bad commit
commit 082e53c2fb5c28179bef45554d1b2157ffc4fdc8
Author: The Dlang Bot 
Date:   Mon Apr 16 01:40:09 2018 +0200

phobos: Merge pull request #6411 from n8sh/allocate-zeroed

https://github.com/dlang/phobos/pull/6411

make/makeArray: take advantage of allocators with smth. faster than
allocate+memset zero
merged-on-behalf-of: Sebastian Wilzbach 

diff --git a/phobos b/phobos
index e13e3889a..7016abafa 16
--- a/phobos
+++ b/phobos
@@ -1 +1 @@
-Subproject commit e13e3889ac9f7dcaec8829af0fb13d60f0391f55
+Subproject commit 7016abafadcdaab1740937fab636c4085feca228
digger: Bisection completed successfully.

--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

class A {
   private int x;
   private(this) int y;
}



I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.


I'm really struggling to come up with any acceptable use case, 
whereby my class would want to have both private and sealed 
variables.( whether the word sealed is used, or private(this) is 
used, is irrelevant to this point though).


Can anyone come up with use case for this code below?

(It may well encourage even poorer software engineering, that 
private morhping into public).


-
class A
{
   private int x; // ok, really public within the module.
   sealed int y; // now really private within the module.
}

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, May 19, 2018 03:32:53 Neia Neutuladh via Digitalmars-d-learn 
wrote:
> > Of course, the most notable case where using == with null is a
> > terrible idea is dynamic arrays, and that's the case where the
> > compiler _doesn't_ complain. Using == with null and arrays is
> > always unclear about the programmer's intent and almost
> > certainly wasn't what the programmer intended. If the
> > programmer cares about null, they should use is. If they care
> > about lengnth, then that's what they should check. Checking
> > null with == is just a huge code smell.
>
> I feel like the array == null version is more explicit about not
> allocating memory. However, I'm paranoid about whether that's
> going to check the pointer instead, so I mostly use array.length
> == 0 instead.

I'm not sure what memory allocations you're worried about. Neither "" nor []
allocates memory, but regardless, if you're looking to check whether arr.ptr
is null, then that's effectively what you get with

arr is null

- though IIRC, it still checks length in that case. It's just that the type
system guarantees that a null dynamic array has a length of 0. You'd have to
do some pretty screwy @system casting to have a null dynamic array with a
length other than 0. But you can always do

arr.ptr is null

Regardless, if you're checking for null, then is does the job, and if what
you care about is whether the array is empty, then that's what

arr.length == 0

and

arr.empty

do. arr == null is just risking confusion, because there's no way to know if
the programmer meant

arr is null

or

arr.empty

Regardless, it's absolutely guaranteed that

arr == null

is going to avoid checking the value of ptr just like

arr == arr2

won't check ptr if length == 0. == only cares that both arrays have the same
number of elements and that they're equal with ==. If length is 0, there's
no need to check the elements to verify that, and if the lengths don't
match, there's no need to check the elements. If you actually used enough
screwed up casts to get two dynamic arrays whose ptr values were null, and
they had different lengths, you still wouldn't get a crash. The _only_ way
to get a segfault from using == with a null dynamic array is if you did
enough screwy @system casts to have two dynamic arrays with the same
non-zero length, and one of them had a null ptr. It wouldn't even crash if
they were both null, because it's going to check the ptrs before comparing
the elements. Regardless, in no real program do you have to worry about
segfaulting with == and dynamic arrays, and you don't have to worry about ==
ever allocating. The closest that you'd get to that would be if you compared
against a non-null array literal. e.g.

arr == [1, 2, 3]

and if the compiler is smart enough, not even that should allocate (though I
don't remember if it's that smart at the moment).

Ultimately, the question of is vs == comes down to clarity of the
programmer's intent.

- Jonathan M Davis

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 16:24:24 UTC, Gheorghe Gabriel wrote:

On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

class A {
   private int x;
   private(this) int y;
}



I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.


Mmm.. that brings me back to the idea of sealed at the class 
level again.


class A
{
   private int x;
   private(this) int y;  // imagine if you have lots of private 
variables.
 // this could become pretty anoying - 
and kinda redundant.

}

class A
{
   private int x;
   sealed int y; // again, what if you have lots of private 
variables that

 // that you really want sealed.
}


// Now. Back to the idea of sealed.
// abosolute consistency of your private variables.
// no redundancy.
// no some 'private', some 'sealed' confusion.
// no some 'private' (but really public) some 'private(this) .. 
confusion.

//
sealed class A{
private int x;
private int y;
}

downside, is adding a new keyword, and getting agreement on what 
that new keyword should be.


So I've come full circle again, and believe my idea is worth 
further consideration.

Re: Of possible interest: fast UTF8 validation

[David Nadlinger via Digitalmars-d]

On Wednesday, 16 May 2018 at 14:48:54 UTC, Ethan Watson wrote:
And even better - LDC doesn't support core.simd and has its own 
intrinsics that don't match the SSE/AVX intrinsics API 
published by Intel.


To provide some context here: LDC only supports the types from 
core.simd, but not the __simd "assembler macro" that DMD uses to 
more or less directly emit the corresponding x86 opcodes.


LDC does support most of the GCC-style SIMD builtins for the 
respective target (x86, ARM, …), but there are two problems with 
this:


 1) As Ethan pointed out, the GCC API does not match Intel's 
intrinsics; for example, it is 
`__builtin_ia32_vfnmsubpd256_mask3` instead of 
`_mm256_mask_fnmsub_pd`, and the argument orders differ as well.


 2) The functions that LDC exposes as intrinsics are those that 
are intrinsics on the LLVM IR level. However, some operations can 
be directly represented in normal, instruction-set-independent 
LLVM IR – no explicit intrinsics are provided for these.


Unfortunately, LLVM doesn't seem to provide any particularly 
helpful tools for implementing Intel's intrinsics API. 
x86intrin.h is manually implemented for Clang as a collection of 
various macros and functions.


It would be seriously cool if someone could write a small tool to 
parse those headers, (semi-)automatically convert them to D, and 
generate tests for comparing the emitted IR against Clang. I'm 
happy to help with the LDC side of things.


 — David

Re: is ==

[Neia Neutuladh via Digitalmars-d-learn]

On Saturday, 19 May 2018 at 01:48:38 UTC, Jonathan M Davis wrote:
Actually, that runtime function has existed since before TDPL 
came out in 2010. It even shows the implementation of the free 
function opEquals (which at the time was in object_.d rather 
than object.d). I'm not even sure that the error message was 
added before the free function version of opEquals was. Maybe 
when that error message was first introduced, it avoided a 
segfault, but if so, it has been a _long_ time since that was 
the case.


Good catch. I overly trusted git blame. The opEquals(Object, 
Object) function was added in February 2010, while the error 
message was added in March 2008.


Of course, the most notable case where using == with null is a 
terrible idea is dynamic arrays, and that's the case where the 
compiler _doesn't_ complain. Using == with null and arrays is 
always unclear about the programmer's intent and almost 
certainly wasn't what the programmer intended. If the 
programmer cares about null, they should use is. If they care 
about lengnth, then that's what they should check. Checking 
null with == is just a huge code smell.


I feel like the array == null version is more explicit about not 
allocating memory. However, I'm paranoid about whether that's 
going to check the pointer instead, so I mostly use array.length 
== 0 instead.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:


So lets stop the pointless gentle mockery and concentrate 
solely on the pointless.


Sounds like a plan!


you mean, follow your lead?  now there's a plan!

I like robust conversations too ;-)

But some semblance on sanity, in that robustness, would also be 
useful.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 17:28:59 UTC, Steven Schveighoffer 
wrote:


You can "simulate" this by putting the classes into their own 
submodules of the same package.




That just another hack to get around the problem.

It's not a solution to removing the problem, from being a problem.

(yeah, I know, not everyone thinks it's a problem.. been there 
done that).


private(this) is a lot easier, than being told you need to 
redesign your whole class layout to accomodate D's 'private is 
really public' concept.


Lets get rid of the problem (that prevents many from using D in 
the first place), rather that constatnly come up with new ways of 
telling them find a way around it.


btw. I only know of two reasons why private is public so far 
(from discussions).


1 - Voldemort types (don't know what it is, and don't care).

2 - unittests (but, if the unit tests, testing your class, are 
outside your class accessing it's private parts, then I have 
trouble considering them to be unittests at all.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 22:10:51 UTC, Maurice Huuskes wrote:


The only thing that's going to drive this discussion forward is 
a few example use-cases (potentially borrowed from other 
languages that ran into similar 'problems'). I am new to D 
myself and how private works did surprise me but using the 
module/package method seems elegant enough to me.


I'll be honest. If people in the D community need to be provided 
with 'use cases' whereby private should not morph in public, then 
ya' all have bigger problems than you realise ;-)


should immutable morph into mutable?
(cause that might be convenient on rare occasions)

should const just morph in non-constant
(cause that might be convenient on rare occasions)

should safe morph into unsafe
(cause that might be convenient on rare occasions)

so why should private morph into public?
(oh.. i know...cause that might be convenient on rare occasions)

it's a really odd design decision to relax that rule just for 
'private', and, it can have a really big impact on software 
quality (not to mention security).


it means, now you have to 'extra care'. cause the compiler won't 
tell you that you accidently accessed the private part - you'll 
have to work that out during your debugging sessions.


or, it means you have to find some hack to get around it.. (one 
class per module).


the option to stop private morphing into public, and the option 
to have compile time check of your semantics, is what the vast 
majority of programmers in the world already enjoy. Come on D. 
get with it!


But in any case, ya' all decided - cause D has no place in my 
development team until I can have more than one class in a 
module, and not be told that my private parts have to be public.


I believe this will continue to hold back D - until it empowers 
the programmer to have that control.

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, May 19, 2018 01:27:59 Neia Neutuladh via Digitalmars-d-learn 
wrote:
> On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions
>
> wrote:
> > Why does D complain when using == to compare with null? Is
> > there really any technical reason? if one just defines == null
> > to is null then there should be no problem. It seems like a
> > pedantic move by who ever implemented it and I'm hoping there
> > is actually a good technical reason for it.
>
> tldr: this error is outdated.
>
> In the days of yore, "obj == null" would call
> "obj.opEquals(null)". Attempting to call a virtual method on a
> null object is a quick path to a segmentation fault. So "obj ==
> null" would either yield false or crash your program.
>
> Except it's worse than that; your opEquals method had to
> explicitly check for null. So if your class had a custom equality
> function, "obj == null" was probably going to segfault no matter
> what.
>
> Because of this common source of errors, in DMD 2.012 (2008), we
> got an error only for the case of comparing with a literal null.
> (The compiler isn't a mind-reader; it doesn't know whether that
> variable will be null when that line of code executes.)
>
> This still sucked, so in 2015 we got a runtime function to handle
> object equality:
> https://github.com/dlang/druntime/blob/dff824eda422b1fcdde5f2fe53120fcd717
> 33aaa/src/object.d#L140
>
> But we haven't removed the error message.

Actually, that runtime function has existed since before TDPL came out in
2010. It even shows the implementation of the free function opEquals (which
at the time was in object_.d rather than object.d). I'm not even sure that
the error message was added before the free function version of opEquals
was. Maybe when that error message was first introduced, it avoided a
segfault, but if so, it has been a _long_ time since that was the case.

> It *is* faster to call "foo is null" than "foo == null", but I
> don't think that's particularly worth a compiler error. The
> compiler could just convert it to "is null" automatically in that
> case.
>
> One casualty of the current state of affairs is that no object
> may compare equal to null.

Honestly, while the compiler probably should just convert obj == null to obj
is null, there really still isn't really a good reason to ever use == with
null. It's _never_ better than using is, and in some cases, it's worse. Of
course, the most notable case where using == with null is a terrible idea is
dynamic arrays, and that's the case where the compiler _doesn't_ complain.
Using == with null and arrays is always unclear about the programmer's
intent and almost certainly wasn't what the programmer intended. If the
programmer cares about null, they should use is. If they care about lengnth,
then that's what they should check. Checking null with == is just a huge
code smell.

So, perhaps the compiler is being pedantic, but it's still telling you the
right thing. It's just insisting about it in the case where it matters less
while not complaining aobut it in the case where it really matters, which is
dumb. So IMHO, if anything, adding an error message for the array case would
make more sense than getting rid of the error with pointers and references.

- Jonathan M Davis

Re: Benchmark Game

[David Nadlinger via Digitalmars-d]

On Saturday, 19 May 2018 at 01:15:10 UTC, RhyS wrote:
More then worth the effort because its used a lot when 
discussions are ongoing regarding languages like Go, C, ... Its 
one of the best form of free advertisement.


D used to be there, but at some point was at the maintainer's 
whim for no specific reason. Isaac has acknowledged the 
arbitrariness of (t)his decision multiple times, and is usually 
quick to add, "but you can host your own copy".


Of course this is only true in a very literal sense – our own 
copy wouldn't get nearly the same exposure than his "official" 
one. Still, it would be useful to have a page comparing optimized 
D results with C/C++, as the Benchmarks Game still enjoys quite a 
bit of popularity despite the maintainer's antics.


 — David

Re: is ==

[Jonathan M Davis via Digitalmars-d-learn]

On Friday, May 18, 2018 23:53:12 IntegratedDimensions via Digitalmars-d-
learn wrote:
> Why does D complain when using == to compare with null? Is there
> really any technical reason? if one just defines == null to is
> null then there should be no problem. It seems like a pedantic
> move by who ever implemented it and I'm hoping there is actually
> a good technical reason for it.

Because == is pretty much never what you want to do with null. How much it
matters depends on the types involved, but if you really want to check for
null, is is definitely the right thing to use.

In the case of pointers and references, is checks that they're pointing to
the same thing. So,

foo is null

directly checks whether the reference or pointer is null. On the other hand,
if you use ==, it's calling some form of opEquals. For pointers, that should
generate identical code, but for class references, it means calling the free
function opEquals. That function will check whether the references are null
before calling opEquals on either of the class objects, but it does add
unnecessary overhead (which, as I understand it, the compiler is
unfortunately not currently able to optimize away) and provides no benefit
over checking with is.

Now, where is vs == _really_ matters (but unfortunately, the compiler does
not complain about) is with dynamic arrays. If you do

arr is null

then the compiler will check whether the array's ptr is null. So, something
like

"" is null

would be false. However, if you use ==, then it compares the length of the
array and then only compares the ptrs if the length is non-zero. So,

"" == null

is true. So, with dynamic arrays, using == with null is a huge code smell.
It _may_ be exactly what the programmer intends, but the odds are pretty
high that they just don't properly understand the difference between is and
==, and they meant to be checking whether the array was actually null but
just ended up checking whether its length was zero (which won't matter for
some code but will cause subtle bugs in any code that treats null as special
- e.g. if that is used to indicate that the array had not been given a
value). Now, because of how == treats null like empty, it _is_ a bit risky
to try and treat null as special with arrays, but anyone wanting to be clear
in their code should either be checking null with is (in which case, they
clearly care about null and not empty), or if they care about length == 0,
they should either be calling empty on the array or explicitly checking the
array's length, since that's what they care about. Much as having == work
with null arrays avoids issues with segfaults due to an array be unitialized
as well as avoids needing to give memory to an array just to have it be
empty, you pretty much never actually care whether an array == null. You
either care that its ptr is null (in which case, is checks that), or you
care about whether its length is 0 (in which case empty or directly checking
length checks that). arr == null is just unclear and likely buggy.

So really, there are _zero_ advantages to comparing null with ==. Using ==
with null risks adding extra overhead, and it often makes the code less
clear. On the other hand, using is makes it crystal clear what you mean and
then does exactly what you mean - check whether the variable is actually
null. So, maybe the compiler is being a bit pedantic by insisting that you
use is rather than ==, but you really should be using is and not == when
checking for null.

- Jonathan M Davis

Re: is ==

[Neia Neutuladh via Digitalmars-d-learn]

On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions 
wrote:
Why does D complain when using == to compare with null? Is 
there really any technical reason? if one just defines == null 
to is null then there should be no problem. It seems like a 
pedantic move by who ever implemented it and I'm hoping there 
is actually a good technical reason for it.


tldr: this error is outdated.

In the days of yore, "obj == null" would call 
"obj.opEquals(null)". Attempting to call a virtual method on a 
null object is a quick path to a segmentation fault. So "obj == 
null" would either yield false or crash your program.


Except it's worse than that; your opEquals method had to 
explicitly check for null. So if your class had a custom equality 
function, "obj == null" was probably going to segfault no matter 
what.


Because of this common source of errors, in DMD 2.012 (2008), we 
got an error only for the case of comparing with a literal null. 
(The compiler isn't a mind-reader; it doesn't know whether that 
variable will be null when that line of code executes.)


This still sucked, so in 2015 we got a runtime function to handle 
object equality:

https://github.com/dlang/druntime/blob/dff824eda422b1fcdde5f2fe53120fcd71733aaa/src/object.d#L140

But we haven't removed the error message.

It *is* faster to call "foo is null" than "foo == null", but I 
don't think that's particularly worth a compiler error. The 
compiler could just convert it to "is null" automatically in that 
case.


One casualty of the current state of affairs is that no object 
may compare equal to null.

Re: Benchmark Game

[RhyS via Digitalmars-d]

On Thursday, 17 May 2018 at 15:39:08 UTC, Andrei Alexandrescu 
wrote:

D is not there. Anyone interested, if it's worth it?


It would be well worth the effort.


More then worth the effort because its used a lot when 
discussions are ongoing regarding languages like Go, C, ... Its 
one of the best form of free advertisement.

Re: is ==

[IntegratedDimensions via Digitalmars-d-learn]

On Friday, 18 May 2018 at 23:58:18 UTC, Uknown wrote:
On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions 
wrote:
Why does D complain when using == to compare with null? Is 
there really any technical reason? if one just defines == null 
to is null then there should be no problem. It seems like a 
pedantic move by who ever implemented it and I'm hoping there 
is actually a good technical reason for it.


D only complains of this when you use ref types (classes or 
AAs). For e.g:

--- test.d
void main()
{
int * p;
assert (p == null && p is null);
class C
{
int x;
}
C c;
assert (c is null);
assert (c == null); //error, c is a reference, so there is 
confusion between opEquals and null check

}
---



or pointers.

Re: is ==

[Uknown via Digitalmars-d-learn]

On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions 
wrote:
Why does D complain when using == to compare with null? Is 
there really any technical reason? if one just defines == null 
to is null then there should be no problem. It seems like a 
pedantic move by who ever implemented it and I'm hoping there 
is actually a good technical reason for it.


D only complains of this when you use ref types (classes or AAs). 
For e.g:

--- test.d
void main()
{
int * p;
assert (p == null && p is null);
class C
{
int x;
}
C c;
assert (c is null);
assert (c == null); //error, c is a reference, so there is 
confusion between opEquals and null check

}
---

is ==

[IntegratedDimensions via Digitalmars-d-learn]

Why does D complain when using == to compare with null? Is there 
really any technical reason? if one just defines == null to is 
null then there should be no problem. It seems like a pedantic 
move by who ever implemented it and I'm hoping there is actually 
a good technical reason for it.

[Issue 18870] Link failure only with -allinst for code in isExpression

[d-bugmail--- via Digitalmars-d-bugs]

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

ag0aep6g  changed:

   What|Removed |Added

   Keywords||link-failure
 CC||ag0ae...@gmail.com

--- Comment #1 from ag0aep6g  ---
Reduced:


void put(R)(R r)
{
r.put();
}

enum hasToString = is(typeof({
static struct S { void put() {} }
enum e = is(typeof(put(S.init)));
}));

static assert(hasToString);
void main() {}


--

Re: Sealed classes - would you want them in D? (v2)

[Maurice Huuskes via Digitalmars-d]

On Friday, 18 May 2018 at 20:30:21 UTC, Dave Jones wrote:

On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:

On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:



It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and 
it hasn't got that far, really.


"Ohh Arya you will never be a lady if you keep walking around 
in your underclothes, even if it is just inside our chambers. 
You'll never have any friends or be popular, no one will ask 
you to the ball. You'll never be a lady."


Ohh the drama...


Let's just stop this part of the convo since it's clearly not 
going to bring us anywhere


So lets stop the pointless gentle mockery and concentrate 
solely on the pointless.


Sounds like a plan!


The only thing that's going to drive this discussion forward is a 
few example use-cases (potentially borrowed from other languages 
that ran into similar 'problems'). I am new to D myself and how 
private works did surprise me but using the module/package method 
seems elegant enough to me.

[Issue 18873] New: sys.msg is not present in the distribution

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18873
   Summary: sys.msg is not present in the distribution
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

The following file[1] is not present after installing DMD64 v2.080.0, fedora
package.

[1]: https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/msg.d

--

Re: Sealed classes - would you want them in D? (v2)

[Dave Jones via Digitalmars-d]

On Friday, 18 May 2018 at 18:12:55 UTC, Chris M. wrote:

On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:



It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and 
it hasn't got that far, really.


"Ohh Arya you will never be a lady if you keep walking around 
in your underclothes, even if it is just inside our chambers. 
You'll never have any friends or be popular, no one will ask 
you to the ball. You'll never be a lady."


Ohh the drama...


Let's just stop this part of the convo since it's clearly not 
going to bring us anywhere


So lets stop the pointless gentle mockery and concentrate solely 
on the pointless.


Sounds like a plan!

Re: Temporary file creation for unittests

[Dr.No via Digitalmars-d-learn]

On Friday, 18 May 2018 at 15:30:05 UTC, Uknown wrote:

On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote:

Hi,

What's the current official position on how to create 
temporary files for use during a unittest. I found


https://github.com/dlang/phobos/pull/5788

but it seems to be languishing in the "we have discussed all 
the issues that no-one will ever have a problem with" phase.


What to do between now and when there is an LDC release that 
has the result of

the merge?


You could use libc's tmpfile with std.stdio.File until a D 
alternative pops up.


http://en.cppreference.com/w/c/io/tmpfile


I've had no idea C++'s got this in the standard library lol a 
while ago I ended up doing this (on Windows):


/// Creates a uniquely named, zero-byte temporary file on disk 
and returns the full path of that file.

/// Returns: the full path of the temp file.
string tempFilename()
{
import  core.sys.windows.windows : GetTempFileNameW, MAX_PATH;
import std.file : tempDir;
import core.stdc.wchar_ : wcslen;
import std.windows.syserror : wenforce;
import std.conv : text, wtext;
wchar[] path = new wchar[MAX_PATH+1];
string dir = tempDir;
wenforce(GetTempFileNameW(dir.wtext.ptr, // temp path
  ("tmp"w).ptr, // dir 
prefix
  0, // id generated 
internally
  path.ptr // path 
buffer
),
"GetTempFileName()");
return path[0 .. wcslen(path.ptr)].text;
}

It's windows-only and call GetTempFileNameW actually so just a 
function wrapper to work with D. There's a way to MAX_PATH but I 
didn't care to implement at time...

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

[kinke via Digitalmars-d]

On Thursday, 17 May 2018 at 19:11:27 UTC, Shachar Shemesh wrote:

On 17/05/18 18:47, kinke wrote:
Since clang is able to compile this struct and do everything 
with it, and since the existence of the move constructor 
requires the precise same type of hooking as is needed in this 
case, I tend to believe that an IR representation of DIP 1014 
is possible.


I checked, and the reason is that D and C++ use a different ABI 
wrt. by-value passing of non-POD arguments. C++ indeed passes a 
reference to a caller-allocated rvalue, not just on Win64; that 
makes it trivial, as there are no moves across call boundaries. 
But your proposal may imply changing the D ABI accordingly.

[Issue 18727] std.math.fmin does not handle nan correctly

[d-bugmail--- via Digitalmars-d-bugs]

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

ki...@gmx.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ki...@gmx.net
 Resolution|--- |FIXED

--- Comment #1 from ki...@gmx.net ---
Resolved by https://github.com/dlang/phobos/pull/6479.

--

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

[Rubn via Digitalmars-d]

On Thursday, 17 May 2018 at 20:25:26 UTC, Shachar Shemesh wrote:
Obviously, Something can be an enum or a boolean. If it is, 
however, then we have to perform a condition to select the 
correct value. The problem with conditionals is that if the CPU 
misses a guess about what they are (and in our case, the CPU is 
going to miss about 50% of the time), they are extremely 
expensive to evaluate.


Performance wise, a much saner approach is:
alias Something = int*;

Of course, this means our struct now has a self referencing 
pointer.


What I'm getting at is that even if there are alternatives to 
structs pointing at themselves, they may not be performance 
wise comparable to pointers.



It's possible to do a branchless condition that chooses between 
two pointers. I think if the hardware (and compiler) support it 
it'll just optimize down to a "cmov".

[Issue 18872] New: -dip1000 does not allow static arrays for types with destructors

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18872
   Summary: -dip1000 does not allow static arrays for types with
destructors
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ajiesk...@gmail.com

@safe:
static struct AType
{   ~this(){}
}

void main()
{   AType[5] array;
}

complains:
reference to local variable 'array' assigned to non-scope parameter 'a' calling
object._ArrayDtor!(CopyPreventer)._ArrayDtor

As I understand it, running a destroyer when finalizing a static array should
work just as well as finalizing a single local with an elaborate destructor.

--

[Issue 18303] Unqual gives weird results for const types

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Basile B.  ---
I don't see any issue here because

static assert(is(T == const) && !is(T == Unqual!T));

is perfectly logic.

--

[Issue 18805] crash in iteration.d

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

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

--- Comment #1 from Basile B.  ---
This is not a crash, this is a compiler error due to the fact that your lambda
is invalid. fold takes lambdas with 2 parameters.

--

[Issue 18805] crash in iteration.d

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--

[Issue 18303] Unqual gives weird results for const types

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
   Hardware|x86 |All
 OS|Windows |All

--

[Issue 18415] Typedef ignores @disabled default constructor

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

   Keywords||pull
 CC||b2.t...@gmx.com
   Hardware|x86 |All
 OS|Windows |All
   Severity|enhancement |normal

--- Comment #1 from Basile B.  ---
Pull: https://github.com/dlang/phobos/pull/6514

--

Re: Sealed classes - would you want them in D? (v2)

[Chris M. via Digitalmars-d]

On Friday, 18 May 2018 at 17:59:04 UTC, Dave Jones wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:



It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and 
it hasn't got that far, really.


"Ohh Arya you will never be a lady if you keep walking around 
in your underclothes, even if it is just inside our chambers. 
You'll never have any friends or be popular, no one will ask 
you to the ball. You'll never be a lady."


Ohh the drama...


Let's just stop this part of the convo since it's clearly not 
going to bring us anywhere

Re: Sealed classes - would you want them in D? (v2)

[Dave Jones via Digitalmars-d]

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:



It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and it 
hasn't got that far, really.


"Ohh Arya you will never be a lady if you keep walking around in 
your underclothes, even if it is just inside our chambers. You'll 
never have any friends or be popular, no one will ask you to the 
ball. You'll never be a lady."


Ohh the drama...

Re: Sealed classes - would you want them in D? (v2)

[Dave Jones via Digitalmars-d]

On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote:


FFS you're so dramatic. First the world is ending because 
private doesnt work as you expected. Then D is utterly useless 
without the changes you want. Now we live in some dystopian 
nightmare where we are all slaves to the Dlang spec.


[..dadadadada...]





Thanks Dave.


You're welcome Joffers.


You make my case  (i.e. The D community is too small, and 
insufficiently diverse to discuss this any further.)


You just reinforce the case that you have a tendency to drama and 
hyperbole.



Except, that I'd add to that, that far too many are pretty 
immature too.


I'd rather be pretty and immature than young and stupid.


Good luck with your dlang thing...18+ years old and still < 
1000 programmers (perhaps a lot less). (and if you have more 
than one class in a file, you have no more encapsulation - I 
love it).


Oh here we go again... if people don't genuflect to Joffer's 
kingly wisdom he storms out like a pouty little tyrant muttering 
"good luck with your crappy language.. hhmmmppff idiots"

[Issue 13741] std.traits.moduleName & packageName do not work with functions that have parameters

[d-bugmail--- via Digitalmars-d-bugs]

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

Basile B.  changed:

   What|Removed |Added

Summary|std.traits.moduleName does  |std.traits.moduleName &
   |not work with functions |packageName do not work
   |that have parameters|with functions that have
   ||parameters

--

Re: Sealed classes - would you want them in D? (v2)

[Steven Schveighoffer via Digitalmars-d]

On 5/18/18 12:07 PM, Gheorghe Gabriel wrote:

Sometimes, I really need to put 2-3 or more different classes in a 
module and I don't want them to share private members (friend classes). 
The current solution is to create an individual module for each class, 
but I don't like it when my class logic-strucrure fits better in the 
same module. A better solution could be private(this). I am sure that D 
really needs something like this. I have been talking with my friend 
programmers for 4 hours and they don't like the fact that D classes 
couldn't protect thier members in the same module. So they stuck on java 
and c#..


You can "simulate" this by putting the classes into their own submodules 
of the same package.


I.e. you want:

module mod;

class C {

 private int _x;
 int x() { return _x; }

}

void foo(C c)
{
   auto x = c._x; // Oops, this should be an error
}

You can do this via:

mod/priv.d:
module mod.priv; // name however you like

class C { ... }

mod/package.d:
module mod;
public import mod.priv; // name isn't really important here

void foo(C c)
{
   auto x = c._x; // Truly an error
}

user.d:

import mod; // imports both foo and C as if they were both in the same 
module


-Steve

Re: Need help with the dmd package on NixOS

[Thomas Mader via Digitalmars-d]

On Friday, 18 May 2018 at 13:15:35 UTC, Johannes Pfau wrote:
As far as I know, that's correct. GCC-based compilers emit ASM 
code only and leave assembling of the objects files to the 
'binutils as' assembler. That's probably the reason they 
assumed it's a binutils bug. For DMD, binutils is not involved 
when creating object files. So this is likely a DMD bug.


That would be my understanding as well.
Probably the problem exists with binutils 2.30 only because it 
changed the format somehow and the linking of the dmd created 
object files doesn't work anymore because of this. The object 
file format created from dmd is not compatible with binutils 
anymore.

Re: Of possible interest: fast UTF8 validation

[Neia Neutuladh via Digitalmars-d]

On Thursday, 17 May 2018 at 23:16:03 UTC, H. S. Teoh wrote:
On Thu, May 17, 2018 at 07:13:23PM +, Patrick Schluter via 
Digitalmars-d wrote: [...]

- the auto-synchronization and the statelessness are big deals.


Yes.  Imagine if we standardized on a header-based string 
encoding, and we wanted to implement a substring function over 
a string that contains multiple segments of different 
languages. Instead of a cheap slicing over the string, you'd 
need to scan the string or otherwise keep track of which 
segment the start/end of the substring lies in, allocate memory 
to insert headers so that the segments are properly 
interpreted, etc.. It would be an implementational nightmare, 
and an unavoidable performance hit (you'd have to copy data 
every time you take a substring), and the @nogc guys would be 
up in arms.


You'd have three data structures: Strand, Rope, and Slice.

A Strand is a series of bytes with an encoding. A Rope is a 
series of Strands. A Slice is a pair of location references 
within a Rope. You probably want a special datastructure to name 
a location within a Rope: Strand offset, then byte offset. Total 
of five words instead of two to pass a Slice, but zero dynamic 
allocations.


This would be a problem for data locality. However, rope-style 
datastructures are handy for some types of string manipulation.


As an alternative, you might have a separate document specifying 
what encodings apply to what byte ranges. Slices would then be 
three words long (pointer to the string struct, start offset, end 
offset). Iterating would cost O(log(S) + M), where S is the 
number of encoded segments and M is the number of bytes in the 
slice.


Anyway, you either get a more complex data structure, or you have 
terrible time complexity, but you don't have both.


And that's assuming we have a sane header-based encoding for 
strings that contain segments in multiple languages in the 
first place. Linguistic analysis articles, for example, would 
easily contain many such segments within a paragraph, or 
perhaps in the same sentence. How would a header-based encoding 
work for such documents?  Nevermind the recent trend of 
liberally sprinkling emojis all over regular text. If every 
emoticon embedded in a string requires splitting the string 
into 3 segments complete with their own headers, I dare not 
imagine what the code that manipulates such strings would look 
like.


"Header" implies that all encoding data appears at the start of 
the document, or in a separate metadata segment. (Call it a start 
index and two bytes to specify the encoding; reserve the first 
few bits of the encoding to specify the width.) It also brings to 
mind HTTP, and reminds me that most documents are either mostly 
ASCII or a heavy mix of ASCII and something else (HTML and XML 
being the forerunners).


If the encoding succeeded at making most scripts single-byte, 
then, testing with https://ar.wikipedia.org/wiki/Main_Page, you 
might get within 15% of UTF-8's efficiency. And then a simple 
sentence like "Ĉu ĝi ŝajnas ankaŭ esti ŝafo?" is 2.64 times as 
long in this encoding as UTF-8, since it has ten encoded 
segments, each with overhead. (Assuming the header supports 
strings up to 2^32 bytes long.)


If it didn't succeed at making Latin and Arabic single-byte 
scripts (and Latin contains over 800 characters in Unicode, while 
Arabic has over three hundred), it would be worse than UTF-16.

Re: auto: useful, annoying or bad practice?

[Neia Neutuladh via Digitalmars-d]

On Friday, 18 May 2018 at 10:09:20 UTC, Chris wrote:
In a way Java has slowly been moving in that direction anyway, 
cf. this answer [2] that reminded me of D's `auto` return type.
[2] 
https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java


Except the return type that you wrote in that case tells you 
almost everything you can do with that value. If you specify the 
return type of a function as `auto`, it tells you nothing. The 
Java equivalent would be to return Object.

Re: Sealed classes - would you want them in D? (v2)

[Gheorghe Gabriel via Digitalmars-d]

On Friday, 18 May 2018 at 15:57:06 UTC, bachmeier wrote:

On Friday, 18 May 2018 at 15:40:52 UTC, KingJo

class A {
   private int x;
   private(this) int y;
}



I agree that this looks a bit strange.
My initial proposal was "sealed" instead "private(this)" today.

Re: Sealed classes - would you want them in D? (v2)

[Gheorghe Gabriel via Digitalmars-d]

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:

[...]


This is simply unavoidable - and, that 'surprise' you mention, 
is already there - it's not dependent on, or in any way 
related, to any proposal that might result from this discussion.


The D 'private is really public in a module' concept, is here 
to stay (sadly, but it's true).




[...]


C++ is a complex beast, as a result of both needing to 
accomodate change (evolve), and not wanting to break backwards 
compatability.


It's still *the* most powerful and flexible tool available for 
programmers.


Beginner programmers would do well to keep that in mind.

A class is just an abstract type, a tool for those that think 
it is useful in the solution for their problem domain.


In any case, this discussion is not about convincing you of the 
value of classes - you should already know that if you are 
programmer.


This discussion (at least my reason for being involved in it) 
is about breaking this idiotic (in my opinion) concept that D 
enforces on 'everyone' - i.e the one class per module, or 
everything is public, and you have no say in it.


I don't necessarily object to the freedom the D module provides 
(i.e to bypass your interfaces, even accidently). What I object 
to is the 'i.e the one class per module, or everything is 
public, and you have no say in it.'


A proposal that empowers the programmer to use the module for 
more than just a container for single class, coupled with 
static compile time verification - i.e you can't accidently 
access your private(this) T as it would be a compile time 
error, would be good for D (in my opinion), because those that 
have enjoyed having this capability in other mainstream 
langauges for literally decades!, won't be shut out from using 
D.


It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and it 
hasn't got that far, really.


To get more programmers, you might want to be more open to 
accomodating their needs too.


Although I do wonder, sometimes, whether the aim if D is just 
to be this cosy little langauge that not many use, except for 
those that do.


Sometimes, I really need to put 2-3 or more different classes in 
a module and I don't want them to share private members (friend 
classes). The current solution is to create an individual module 
for each class, but I don't like it when my class logic-strucrure 
fits better in the same module. A better solution could be 
private(this). I am sure that D really needs something like this. 
I have been talking with my friend programmers for 4 hours and 
they don't like the fact that D classes couldn't protect thier 
members in the same module. So they stuck on java and c#..

Re: Sealed classes - would you want them in D? (v2)

[bachmeier via Digitalmars-d]

On Friday, 18 May 2018 at 15:40:52 UTC, KingJoffrey wrote:

This discussion (at least my reason for being involved in it) 
is about breaking this idiotic (in my opinion) concept that D 
enforces on 'everyone' - i.e the one class per module, or 
everything is public, and you have no say in it.


I don't necessarily object to the freedom the D module provides 
(i.e to bypass your interfaces, even accidently). What I object 
to is the 'i.e the one class per module, or everything is 
public, and you have no say in it.'


I'm not saying I oppose making this change, but "evolution of the 
language" takes the form of adding features but never eliminating 
any. If I see


class A {
   private int x;
   private(this) int y;
}

it kind of makes my head hurt, and I've been using D for five 
years. The justification I've seen for complications like private 
vs public is that it's necessary for large programs. There's 
something wrong if a single module is considered large.


Unlike most of the people that post here, I work with beginning 
programmers. In almost all cases, decisions are made on the basis 
of appeal to 20-year C++ veterans, but at least I can say I 
raised the issue.

[Issue 18768] object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

[d-bugmail--- via Digitalmars-d-bugs]

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 18768] object.getArrayHash with custom toHash shouldn't just sum hashes of array elements

[d-bugmail--- via Digitalmars-d-bugs]

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

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

https://github.com/dlang/druntime/commit/5064012515d2954fb0884f422c1fd158a146
Fix Issue 18768 - object.getArrayHash with custom toHash shouldn't just sum
hashes of array elements

https://github.com/dlang/druntime/commit/7605989c06ce07989ac6b601c17537c05645e185
Merge pull request #2166 from n8sh/issue-18768-getArrayHash

Fix Issue 18768 - object.getArrayHash with custom toHash shouldn't just sum
hashes of array elements
merged-on-behalf-of: Jacob Carlborg 

--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 14:32:33 UTC, bachmeier wrote:


As clean and uncontroversial as this proposal might be, it 
unfortunately doesn't resolve the biggest issue. If you try to 
write Java code in D, you're still going to be using private, 
and you're still going to be caught by surprise.


This is simply unavoidable - and, that 'surprise' you mention, is 
already there - it's not dependent on, or in any way related, to 
any proposal that might result from this discussion.


The D 'private is really public in a module' concept, is here to 
stay (sadly, but it's true).



And this is another step in the direction of C++ (we need to 
think of beginning programmers every so often) so there are 
costs. It's possible that since I rarely use classes I'm not 
seeing the large benefits.


C++ is a complex beast, as a result of both needing to accomodate 
change (evolve), and not wanting to break backwards compatability.


It's still *the* most powerful and flexible tool available for 
programmers.


Beginner programmers would do well to keep that in mind.

A class is just an abstract type, a tool for those that think it 
is useful in the solution for their problem domain.


In any case, this discussion is not about convincing you of the 
value of classes - you should already know that if you are 
programmer.


This discussion (at least my reason for being involved in it) is 
about breaking this idiotic (in my opinion) concept that D 
enforces on 'everyone' - i.e the one class per module, or 
everything is public, and you have no say in it.


I don't necessarily object to the freedom the D module provides 
(i.e to bypass your interfaces, even accidently). What I object 
to is the 'i.e the one class per module, or everything is public, 
and you have no say in it.'


A proposal that empowers the programmer to use the module for 
more than just a container for single class, coupled with static 
compile time verification - i.e you can't accidently access your 
private(this) T as it would be a compile time error, would be 
good for D (in my opinion), because those that have enjoyed 
having this capability in other mainstream langauges for 
literally decades!, won't be shut out from using D.


It will attract more programmers, not less - and trust me, D 
better get more programmers using it, cause 18 years on, and it 
hasn't got that far, really.


To get more programmers, you might want to be more open to 
accomodating their needs too.


Although I do wonder, sometimes, whether the aim if D is just to 
be this cosy little langauge that not many use, except for those 
that do.

Re: Temporary file creation for unittests

[Uknown via Digitalmars-d-learn]

On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote:

Hi,

What's the current official position on how to create temporary 
files for use during a unittest. I found


https://github.com/dlang/phobos/pull/5788

but it seems to be languishing in the "we have discussed all 
the issues that no-one will ever have a problem with" phase.


What to do between now and when there is an LDC release that 
has the result of

the merge?


You could use libc's tmpfile with std.stdio.File until a D 
alternative pops up.


http://en.cppreference.com/w/c/io/tmpfile

Temporary file creation for unittests

[Russel Winder via Digitalmars-d-learn]

Hi,

What's the current official position on how to create temporary files for use
during a unittest. I found 

https://github.com/dlang/phobos/pull/5788

but it seems to be languishing in the "we have discussed all the issues that
no-one will ever have a problem with" phase.

What to do between now and when there is an LDC release that has the result of
the merge?
 
-- 
Russel.
==
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


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

Re: C API / const char *text / std.string.toStringz pointer is always NULL on C side

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

On Friday, 18 May 2018 at 14:06:11 UTC, Robert M. Münch wrote:
So, having a wrong return-type here, resulted in the const char 
*text parameter always being NULL. Not sure I understand the 
relation but looks strange to me... at least not very obvious.


A value struct return is actually done via a hidden pointer 
parameter (so the function can construct it in-place for the 
caller, a standard optimization), so it just shifted all the 
other arguments to the side, causing one of those 0's to be 
interpreted as the string.

Re: Sealed classes - would you want them in D? (v2)

[bachmeier via Digitalmars-d]

On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:


Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin 
for multiple classes.

Example:

string var = "private(this) var;";

class A {
mixin(var);
}

class B {
mixin(var);
}


As clean and uncontroversial as this proposal might be, it 
unfortunately doesn't resolve the biggest issue. If you try to 
write Java code in D, you're still going to be using private, and 
you're still going to be caught by surprise. And this is another 
step in the direction of C++ (we need to think of beginning 
programmers every so often) so there are costs. It's possible 
that since I rarely use classes I'm not seeing the large benefits.

[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Mike Franklin  ---
Test case without dependency on std.experiment.allocator:

struct S 
{
~this(){}   
}

bool f()
{
try
{
return true;
}
finally
{
_ArrayDtor([S(), S()]);
}
}

void main()
{
enum b = f();
}

--

Re: C API / const char *text / std.string.toStringz pointer is always NULL on C side

[Robert M. Münch via Digitalmars-d-learn]

On 2018-05-16 17:46:59 +, Steven Schveighoffer said:


Well, for C see above on the D side:

extern(C) {
  result myfunc(double x, double y, const char *text, stuff 
*myStuff, bool measureOnly);

}


Shouldn't the result be a pointer?


Indeed. And you know what? That was causing the problem.

So, having a wrong return-type here, resulted in the const char *text 
parameter always being NULL. Not sure I understand the relation but 
looks strange to me... at least not very obvious.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Template instantiation fails on Linux, succeeds on Windows

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/17/18 7:33 PM, Bastiaan Veelo wrote:

On Thursday, 17 May 2018 at 23:18:32 UTC, Basile B. wrote:

On Thursday, 17 May 2018 at 22:07:46 UTC, Bastiaan Veelo wrote:

Hi!

The code in [1] compiles and runs flawlessly on Windows, but not on 
Linux (neither run.dlang nor Travis docker image). Any idea what can 
be done?


Hello. Yes, add `import core.stdc.stdarg;` in your module and it works.
I don't know why it's not required on windows, this is strange.


Great! Thanks a lot, Basile!

Seems there is room for improvement somewhere, a better error message at 
the least.


Interestingly, the error was better before:

https://run.dlang.io/is/BgvH4w

Tested on all compilers, up to 2.072.1, it results in:

onlineapp.d(1): Error: '__va_argsave_t' is not defined, perhaps you need 
to import core.vararg; ?
onlineapp.d(1): Error: function onlineapp.foo must import core.vararg to 
use variadic functions


In 2.072.2, it starts saying:

Error: undefined identifier '__va_list_tag'

The previous error was much better, but this to me is a huge code smell. 
Why do we have to import certain modules to use actual language 
features? Just to *define* a function, but not do anything inside it? 
I'd understand if this was a linker error, but surely the compiler can 
know to auto-import something, or at least spit out the proper extern(C) 
declarations?


Note that your code works if I import core.vararg outside the function, 
you don't need core.stdc.stdarg. The import cannot be *inside* the function.


-Steve

Re: vibe.d 0.7.33 maintenance release

[Márcio Martins via Digitalmars-d-announce]

On Wednesday, 16 May 2018 at 08:48:15 UTC, Sönke Ludwig wrote:
Being the final public release on the 0.7.x branch, this 
version on DMD 2.068.2 up to DMD 2.080.0 and LDC 1.9.0. It 
includes some major fixes and improvements backported from the 
0.8.x branch. Since this marks the last 0.7.x release, all code 
depending on it should now be upgraded to 0.8.3 or later.


Change log:


DUB package:



Comparing with 0.7.x, how production-ready would you say the 
0.8.x branch is, and what are the main advantages?


Thank you for the awesome work!

Re: Sealed classes - would you want them in D? (v2)

[Mike Parker via Digitalmars-d]

On Friday, 18 May 2018 at 12:42:05 UTC, KingJoffrey wrote:



How hard is it to convince people, that being able to have the 
compiler detect semantic errors that break your defined 
interface is actually a good thing. I mean really. I've had 
this capability in major languages for decades.


Let D empower the programmer in this case, by giving that back 
to them (as an opt-in)


Two points:

1) the status quo in D is not generally viewed as a violation of 
encapsulation (if you change the class, you can also change the 
module)


2) there's a simple workaround already in place for people who 
really, really, want to do it


The DIP will need to provide counters to both of these points. 
One example for point one off the top of my head --


Currently, if you do something like change the name of a private 
member, anything in the module still referencing the old symbol 
will cause a compiler error and you can fix it immediately.


But, say you have this code:

```
class Foo {
   private int _x;
   int x { return _x; }
}

void printFoo(Foo f) { writeln("Foo: ", f._x);
```

And later, you decide you want to track all accesses to _x in a 
foo instance:


```
class Foo {
   private int _x;
   private int _xHits;
   int x() {
  ++_xHits;
  return _x;
}

// Oops!
void printFoo(Foo f) { writeln("Foo: ", f._x);
```

This would only manifest itself at runtime and in a large module 
could be one of those bugs that keeps you scratching your head 
for much longer than it ought to. The same thing can happen 
through accessing _x internally in the class, but the surface 
area is smaller and the bug could (theoretically) be caught more 
quickly (and preventing even this is the rationale behind the 
Java style of using accessors internally).


So that's the sort of thing a DIP would need to be doing. 
Essentially, answering the questions: what are the holes in the 
status quo ("encapsulation is violated" doesn't cut it -- solid 
examples of real issues are required), and how is the proposed 
solution superior to the workaround?

[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Mike Franklin  ---
Attempted fix: https://github.com/dlang/dmd/pull/8260

--

Re: Need help with the dmd package on NixOS

[Johannes Pfau via Digitalmars-d]

On Friday, 18 May 2018 at 11:28:30 UTC, Mike Franklin wrote:

On Friday, 18 May 2018 at 10:28:37 UTC, Thomas Mader wrote:

On Friday, 11 May 2018 at 04:27:20 UTC, Thomas Mader wrote:
My suspicion about the switch to glibc 2.27 being the problem 
was wrong.
I did a very timeconsuming bisection and found the problem 
commit to be the one which bumped binutils to 2.30.


Can somebody help me to answer the question from 
https://sourceware.org/bugzilla/show_bug.cgi?id=23199#c4 
please.
The object is created by the dmd backend but where in the code 
is binutils used?


I'm not sure I understand.  Does binutils need to be used to 
generated an object file?  My understanding is the DMD creates 
the object file without the help of binutils.


As far as I know, that's correct. GCC-based compilers emit ASM 
code only and leave assembling of the objects files to the 
'binutils as' assembler. That's probably the reason they assumed 
it's a binutils bug. For DMD, binutils is not involved when 
creating object files. So this is likely a DMD bug.


-- Johannes

Re: Sealed classes - would you want them in D? (v2)

[Chris M. via Digitalmars-d]

On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:


You may not need a new word at all. You can also enhance 
private to take arguments. Package already does this. You can 
give private a symbol list that says which symbols this is 
private for. So:


class A {
  private int x;
  private(A) int y;
}
void main() {
  A a = new A();
  a.x = 7; // ok, it's private to module
  a.y = 3; // error, it's sealed to class
}

Cheers,
- Ali


Don't really have a stake in the convo, but I'll jump in to say 
this looks like a solid solution to me (also agree 'this' instead 
of classname).

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 12:51:42 UTC, Steven Schveighoffer 
wrote:


Awesome, I love being on lists!


Well, just remember to vote *down* the dip then, cause if doesn't 
get through, your quote be on my list of 'why OOP programmers 
should not consider D' ;-)




It happened to me too!

https://forum.dlang.org/post/fbs28v$2ss6$1...@digitalmars.com

And then I learned how it worked and said "oh, ok, makes sense".



How can implicately breaking encapsulation make sense to an OOP 
programmer?


How can 'I don't care about your defined interface, I'm gunna 
bypass it' - make sense to an OOP programmer?


Let's be realistic here. The 'one class per module or it all 
breaks down' model, just won't suit 'many' programmers.





Hm.. I see you are still here arguing though. Interesting.



Well, some good ideas (much better than mine) somehow popped up.

So there's hope for D yet.

Re: Sealed classes - would you want them in D? (v2)

[aliak via Digitalmars-d]

On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:

private(this) int y;

This keeps the implementation simple and the scope focused.


Yeah, maybe more focused at the beginning would be better. A 
comma separated list can be added later if deemed worthy.


And agreed, the java recommendation might help build a case. 
There's also the argument of avoiding state related bugs in 
larger code bases that is managed through computed properties:


class A {
  @property int i() {
// fix internal state due to access
return _i;
  }
  private int _i;
}

Of course these are all solved by putting a class in its own 
module anyway. I can see this being problematic the bigger code 
bases get though. I.e. programmer A adds an extension function in 
module M that is 6000 lines long and doesn't see that he should 
do A.i and not A._i - bug maybe goes unnoticed for long time.


Only thing I can actually think of is if you want to have 
extension functions on classes in the same module and only want 
some variables to be accessible from extension functions but keep 
other truly private, you can't do this. So it makes writing code 
in an extension based style harder. But then you can argue if an 
extension needs to access private(this) variables then it should 
be module private anyway. So meh...

[Issue 18742] std.regex: Using CodePointSet in AAs breaks if reference count changes

[d-bugmail--- via Digitalmars-d-bugs]

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

vladvi...@gmail.com changed:

   What|Removed |Added

   Assignee|vladvi...@gmail.com |nob...@puremagic.com

--

Re: Sealed classes - would you want them in D? (v2)

[Steven Schveighoffer via Digitalmars-d]

On 5/17/18 10:08 PM, KingJoffrey wrote:

On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer wrote:


D's main draw is not OOP. So if you are here for OOP goodies, then you 
are definitely better off looking elsewhere.




I'll add that too my list of D forum quotes.


Awesome, I love being on lists!



That being said, D does have OOP, and many OOP programmers are fine 
with the current state of affairs.


How many OOP programmers in the world?


Too many.


How many of them use D?


Only the good ones ;)


Your use of the word 'many' is questionable.


Many means more than a few.


Not disputing that, it's a reasonable choice either way.


And yet, the D community is intent on not empowering the programmer to 
make that choice themselves.


I'm not aware of a programming language that lets the user decide what 
keywords are supposed to mean. If there is one, let me know so I can 
stay away.




Unfortunately, that fails the first time you see code that has 
"sealed" on it, and have to go figure out what exactly that means.


That's what happend to me, with the 'D version' of 'private'.


It happened to me too!

https://forum.dlang.org/post/fbs28v$2ss6$1...@digitalmars.com

And then I learned how it worked and said "oh, ok, makes sense".

You can say the same for every other attribute D has, that I had never 
seen before.


It's a nonsense argument that many use, to prevent change.


The argument is that it *does* add to the load needed to understand the 
language, so it better be worth it. It's not a nonsense argument, every 
extra attribute adds extra cognitive load.


So saying the change would be "blind" to those people who don't care 
about it is not true. When you see an attribute that you don't 
understand, you need to look it up to see what it does, it may do 
something you don't want it to.


You're welcome to write a DIP, but I don't see a very good chance for 
acceptance given the discussions on this subject.




I agree. The D community is too small, and insufficiently diverse to 
discuss this any further.


Hm.. I see you are still here arguing though. Interesting.

It's funny how we build programming languages to serve us, but we end up 
serving them.


This should go on your quotes list I think. Or maybe a fortune cookie.

-Steve

[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #1 from Mike Franklin  ---
Works in 2.079.  Begins to fail in 2.080.

https://run.dlang.io/is/iBdoDg

--

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:


Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin 
for multiple classes.


Also, it also removes the redundancy of referring to the actual 
class name - as in:


private(this) int i; // Nice!

private(yourclassname) int i; // yuk. unneccesary redundancy.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 12:32:30 UTC, Mike Parker wrote:


private(this) int y;



I think that might be it. So clean.


This keeps the implementation simple and the scope focused. If 
a DIP were put forward, I think this would be the approach to 
take. Though a fairly strong case will still need to be made as 
to why this is beneficial (use cases, example code, etc). To 
bolster the case, I would look at the reasoning behind the 
recommendation in Java that classes use the public API 
internally rather than manipulating member variables directly 
to improve maintainability.


How hard is it to convince people, that being able to have the 
compiler detect semantic errors that break your defined interface 
is actually a good thing. I mean really. I've had this capability 
in major languages for decades.


Let D empower the programmer in this case, by giving that back to 
them (as an opt-in)

Re: Sealed classes - would you want them in D? (v2)

[aliak via Digitalmars-d]

On Friday, 18 May 2018 at 12:26:14 UTC, Gheorghe Gabriel wrote:

Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin 
for multiple classes.

Example:

string var = "private(this) var;";

class A {
mixin(var);
}

class B {
mixin(var);
}


Me like :)

You can have both so you can do what you say with private(this) 
and also allow access from other classes/structs


class A { private(this, B) onlyForMeAndTypeB; }

Essentially a more fine grained version of C++'s friend.

Re: Sealed classes - would you want them in D? (v2)

[Mike Parker via Digitalmars-d]

On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:

You may not need a new word at all. You can also enhance 
private to take arguments. Package already does this. You can 
give private a symbol list that says which symbols this is 
private for. So:


class A {
  private int x;
  private(A) int y;
}
void main() {
  A a = new A();
  a.x = 7; // ok, it's private to module
  a.y = 3; // error, it's sealed to class
}



That's actually a decent way to go about it. It matches the 
package syntax and avoids new keywords. It's also not as onerous 
as repurposing an existing keyword (like `module`), nor does it 
cause any breakage. Though, I would argue that rather than 
allowing any old symbol, it be restricted to `this`:


private(this) int y;

This keeps the implementation simple and the scope focused. If a 
DIP were put forward, I think this would be the approach to take. 
Though a fairly strong case will still need to be made as to why 
this is beneficial (use cases, example code, etc). To bolster the 
case, I would look at the reasoning behind the recommendation in 
Java that classes use the public API internally rather than 
manipulating member variables directly to improve maintainability.

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:


I think this code has cleaner sintax:

class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}


I agree. I actually like your solution much better, and, it's 
less likely to cause confusion with use of the word 'sealed', 
because it's applied to the variable (and therefore people from 
other languages won't get confused having sealed applied at the 
class level - unless there are languages that applye sealed at 
the variable level).


Now, you write that DIP (that everyone will ignore).

Re: Sealed classes - would you want them in D? (v2)

[Gheorghe Gabriel via Digitalmars-d]

On Friday, 18 May 2018 at 12:16:55 UTC, aliak wrote:

On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:

[...]


I think this code has cleaner sintax:

class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}


You may not need a new word at all. You can also enhance 
private to take arguments. Package already does this. You can 
give private a symbol list that says which symbols this is 
private for. So:


class A {
  private int x;
  private(A) int y;
}
void main() {
  A a = new A();
  a.x = 7; // ok, it's private to module
  a.y = 3; // error, it's sealed to class
}

Cheers,
- Ali


Good idea. Or: private(this)
Because using "this" it is easier tu put this code in a mixin for 
multiple classes.

Example:

string var = "private(this) var;";

class A {
mixin(var);
}

class B {
mixin(var);
}

[Issue 18871] DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

mmcoma...@gmail.com changed:

   What|Removed |Added

 CC||mmcoma...@gmail.com

--

[Issue 18871] New: DMD "illegal hardware instruction" crash

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18871
   Summary: DMD  "illegal hardware instruction" crash
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mmcoma...@gmail.com

After upgrade to "DMD64 D Compiler v2.080.0-dirty" my code crashes. 

Minimized code:

import std.experimental.allocator;
import std.experimental.allocator.mallocator;

struct Vector{
~this(){}   
}

struct Bucket{
Vector[2] elements;
}

struct BucketsChain{
Bucket* addBucket(){
return Mallocator.instance.make!Bucket;
}
}






Backtrace:
#0  0x563b505051f1 in Interpreter::visit(CallExp*) ()
#1  0x563b504f333c in Interpreter::visit(ExpStatement*) ()
#2  0x563b504f50bd in Interpreter::visit(TryFinallyStatement*) ()
#3  0x563b504f3413 in Interpreter::visit(CompoundStatement*) ()
#4  0x563b504f3413 in Interpreter::visit(CompoundStatement*) ()
#5  0x563b504f23ae in
_D3dmd10dinterpret9interpretFCQBc4func15FuncDeclarationPSQCdQCc10InterStatePSQCx4root5array__T5ArrayTCQDw10expression10ExpressionZQBkQBgZQBk
()
#6  0x563b505050a5 in Interpreter::visit(CallExp*) ()
#7  0x563b504a29cb in ctfeInterpret(Expression*) ()
#8  0x563b50456a90 in InitializerSemanticVisitor::visit(ExpInitializer*) ()
#9  0x563b5039f8c5 in Semantic2Visitor::visit(VarDeclaration*) ()
#10 0x563b503a080e in Semantic2Visitor::visit(AttribDeclaration*) ()
#11 0x563b503a080e in Semantic2Visitor::visit(AttribDeclaration*) ()
#12 0x563b503a080e in Semantic2Visitor::visit(AttribDeclaration*) ()
#13 0x563b503a080e in Semantic2Visitor::visit(AttribDeclaration*) ()
#14 0x563b503a080e in Semantic2Visitor::visit(AttribDeclaration*) ()
#15 0x563b5039f1e2 in Semantic2Visitor::visit(TemplateInstance*) ()
#16 0x563b504b5916 in
_D3dmd10dsymbolsem24templateInstanceSemanticFCQBs9dtemplate16TemplateInstancePSQCz6dscope5ScopePSQDr4root5array__T5ArrayTCQEq10expression10ExpressionZQBkZv
()
#17 0x563b50474e26 in ExpressionSemanticVisitor::visit(ScopeExp*) ()
#18 0x563b5039ebca in
_D3dmd10staticcond19evalStaticConditionFPSQBo6dscope5ScopeCQCf10expression10ExpressionQBcKbZb
()
#19 0x563b5039e78b in Semantic2Visitor::visit(StaticAssert*) ()
#20 0x563b503b3c9e in
StatementSemanticVisitor::visit(StaticAssertStatement*) ()
#21 0x563b503a489f in StatementSemanticVisitor::visit(CompoundStatement*)
()
#22 0x563b503936a2 in Semantic3Visitor::visit(FuncDeclaration*) ()
#23 0x563b50478d3d in ExpressionSemanticVisitor::visit(FuncExp*) ()
#24 0x563b503c8a50 in semanticTraits(TraitsExp*, Scope*) ()
#25 0x563b50481073 in ExpressionSemanticVisitor::visit(TraitsExp*) ()
#26 0x563b50457f59 in InferTypeVisitor::visit(ExpInitializer*) ()
#27 0x563b504c3ab8 in DsymbolSemanticVisitor::visit(VarDeclaration*) ()
#28 0x563b504c8a3c in
DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) ()
#29 0x563b504bfd5e in TemplateInstance::tryExpandMembers(Scope*) ()
#30 0x563b504b57fb in
_D3dmd10dsymbolsem24templateInstanceSemanticFCQBs9dtemplate16TemplateInstancePSQCz6dscope5ScopePSQDr4root5array__T5ArrayTCQEq10expression10ExpressionZQBkZv
()
#31 0x563b50474e26 in ExpressionSemanticVisitor::visit(ScopeExp*) ()
#32 0x563b5039ebca in
_D3dmd10staticcond19evalStaticConditionFPSQBo6dscope5ScopeCQCf10expression10ExpressionQBcKbZb
()
#33 0x563b5039ec61 in
_D3dmd10staticcond19evalStaticConditionFPSQBo6dscope5ScopeCQCf10expression10ExpressionQBcKbZb
()
#34 0x563b5039eb27 in
_D3dmd10staticcond19evalStaticConditionFPSQBo6dscope5ScopeCQCf10expression10ExpressionQBcKbZb
()
#35 0x563b50525693 in StaticIfCondition::include(Scope*) ()
#36 0x563b503ea932 in ConditionalStatement::flatten(Scope*) ()
#37 0x563b503a47be in StatementSemanticVisitor::visit(CompoundStatement*)
()
#38 0x563b503936a2 in Semantic3Visitor::visit(FuncDeclaration*) ()
#39 0x563b50391552 in Semantic3Visitor::visit(TemplateInstance*) ()
#40 0x563b504b5ab8 in
_D3dmd10dsymbolsem24templateInstanceSemanticFCQBs9dtemplate16TemplateInstancePSQCz6dscope5ScopePSQDr4root5array__T5ArrayTCQEq10expression10ExpressionZQBkZv
()
#41 0x563b5041c39e in
_D3dmd9dtemplate15functionResolveFPSQBi11declaration5MatchCQCf7dsymbol7DsymbolSQCz7globals3LocPSQDq6dscope5ScopePSQEi4root5array__T5ArrayTCQFhQz10rootobject10RootObjectZQBmCQGp5mtype4TypePSQHfQCxQCv__TQCsTCQHw10expression10ExpressionZQDzPPxaZv
()
#42 0x563b50398efd in resolveFuncCall(Loc const&, Scope*, Dsymbol*,
Array*, Type*, Array*, int) ()
#43 0x563b5047b465 in ExpressionSemanticVisitor::visit(CallExp*) ()
#44 0x563b5048610b in resolveUFCSProperties(Scope*, Expression*,
Expression*) ()
#45 0x563b50486d8e in

Re: Sealed classes - would you want them in D? (v2)

[aliak via Digitalmars-d]

On Friday, 18 May 2018 at 12:00:58 UTC, Gheorghe Gabriel wrote:

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even 
better ;-)


Add an new attribute to class, named 'sealed'.

No, not sealed as in Scala.

No, not sealed as in C#

sealed as in oxford dictionary (close securely, non-porous).

when sealed is applied on the class, this means the class is 
sealed.


the sealed attribute only makes sense within a module, and 
affects nothing outside of the module.


When sealed is applied to the class, then, interfacing to a 
class within a module, from code outside that class - but 
still within the module, can now only occur via the published 
interface of the class.


outside code in the module, can no longer directly access your 
private parts!


The class is sealed.


I think this code has cleaner sintax:

class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}


You may not need a new word at all. You can also enhance private 
to take arguments. Package already does this. You can give 
private a symbol list that says which symbols this is private 
for. So:


class A {
  private int x;
  private(A) int y;
}
void main() {
  A a = new A();
  a.x = 7; // ok, it's private to module
  a.y = 3; // error, it's sealed to class
}

Cheers,
- Ali

Re: Sealed classes - would you want them in D? (v2)

[Gheorghe Gabriel via Digitalmars-d]

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:
I propose an idea, for discussion (robust discussion even 
better ;-)


Add an new attribute to class, named 'sealed'.

No, not sealed as in Scala.

No, not sealed as in C#

sealed as in oxford dictionary (close securely, non-porous).

when sealed is applied on the class, this means the class is 
sealed.


the sealed attribute only makes sense within a module, and 
affects nothing outside of the module.


When sealed is applied to the class, then, interfacing to a 
class within a module, from code outside that class - but still 
within the module, can now only occur via the published 
interface of the class.


outside code in the module, can no longer directly access your 
private parts!


The class is sealed.


I think this code has cleaner sintax:

class A {
private int x;
sealed int y;
}
void main() {
A a = new A();
a.x = 7; // ok, it's private to module
a.y = 3; // error, it's sealed to class
}

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 11:41:33 UTC, KingJoffrey wrote:

..


I should have also added:

good luck rememebering to use private, cause public is default 
(ha haa haaa).


then again, private is public, so I guess it doesn't matter.

enjoy those debugging sessions...

Re: Sealed classes - would you want them in D? (v2)

[KingJoffrey via Digitalmars-d]

On Friday, 18 May 2018 at 09:07:57 UTC, Dave Jones wrote:


FFS you're so dramatic. First the world is ending because 
private doesnt work as you expected. Then D is utterly useless 
without the changes you want. Now we live in some dystopian 
nightmare where we are all slaves to the Dlang spec.


[..dadadadada...]


Thanks Dave.

You make my case  (i.e. The D community is too small, and 
insufficiently diverse to discuss this any further.)


Except, that I'd add to that, that far too many are pretty 
immature too.


Good luck with your dlang thing...18+ years old and still < 1000 
programmers (perhaps a lot less). (and if you have more than one 
class in a file, you have no more encapsulation - I love it).

Re: Need help with the dmd package on NixOS

[Mike Franklin via Digitalmars-d]

On Friday, 18 May 2018 at 10:28:37 UTC, Thomas Mader wrote:

On Friday, 11 May 2018 at 04:27:20 UTC, Thomas Mader wrote:
My suspicion about the switch to glibc 2.27 being the problem 
was wrong.
I did a very timeconsuming bisection and found the problem 
commit to be the one which bumped binutils to 2.30.


Can somebody help me to answer the question from 
https://sourceware.org/bugzilla/show_bug.cgi?id=23199#c4 please.
The object is created by the dmd backend but where in the code 
is binutils used?


I'm not sure I understand.  Does binutils need to be used to 
generated an object file?  My understanding is the DMD creates 
the object file without the help of binutils.  The only time 
binutils is really called is when it calls `gcc` to do  the link 
at 
https://github.com/dlang/dmd/blob/b61d1c8989bed54489c9c7eb5acc2e1f4312b8c6/src/dmd/link.d#L157


Mike

Re: Help me please fix the bug

[Majestio via Digitalmars-d]

On Friday, 18 May 2018 at 10:18:42 UTC, Seb wrote:

On Friday, 18 May 2018 at 09:59:27 UTC, Majestio wrote:

On Friday, 18 May 2018 at 06:02:46 UTC, Mike Franklin wrote:

[...]


About dmd-master-2018-05-18 ...

build.sh:
=
#/bin/sh

[...]


FWIW instead of such a build script, you could have used the 
install script which does this for you:


curl https://dlang.org/install.sh | bash -s dmd-nightly

Full docs: https://dlang.org/install


Thanks I'll know.

Re: Need help with the dmd package on NixOS

[Thomas Mader via Digitalmars-d]

On Friday, 11 May 2018 at 04:27:20 UTC, Thomas Mader wrote:
My suspicion about the switch to glibc 2.27 being the problem 
was wrong.
I did a very timeconsuming bisection and found the problem 
commit to be the one which bumped binutils to 2.30.


Can somebody help me to answer the question from 
https://sourceware.org/bugzilla/show_bug.cgi?id=23199#c4 please.
The object is created by the dmd backend but where in the code is 
binutils used?

[Issue 5127] Template instantiation arguments with CTFE on expressions

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com
Summary|Template instantiation  |Template instantiation
   |arguments with integer  |arguments with CTFE on
   |operations  |expressions

--

[Issue 10318] Built-in array sort usage warning, then deprecation, and finally removal

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10318
Issue 10318 depends on issue 5124, which changed state.

Issue 5124 Summary: Make std.algorithm.sort weakly pure
https://issues.dlang.org/show_bug.cgi?id=5124

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--

[Issue 5124] Make std.algorithm.sort weakly pure

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #2 from Dmitry Olshansky  ---
The provided example now compiles, so whatever changes required were introduced
w/o ever noticing this ticket. Just clarifies my understanding that NOBODY is
looking at enhancements in Bugzilla (except for select few), but rather only
bugs.

///

import std.algorithm: sort;
import std.traits: FunctionAttribute, functionAttributes;

alias FunctionAttribute FA; // shorten the enum name

pure int[] foo1(int[] arr) {
sort(arr);
return arr;
}

pure int[] foo2(int[] arr) {
sort!q{ a > b }(arr);
return arr;
}

pure bool myComp1(int x, int y) { return x > y; }
pure int[] foo3(int[] arr) {
sort!(myComp1)(arr);
return arr;
}

pure int[] foo4(int[] arr) {
static pure bool myComp2(int x, int y) { return x > y; }
// static assert(functionAttributes!(myComp2) & FA.PURE); // asserts
//sort!(myComp2)(arr);
return arr;
}

void main() {
assert(foo1([5, 1, 7, 4]) == [1, 4, 5, 7]);
assert(foo2([5, 1, 7, 4]) == [7, 5, 4, 1]);
assert(foo3([5, 1, 7, 4]) == [7, 5, 4, 1]);
//assert(foo4([5, 1, 7, 4]) == [7, 5, 4, 1]);
}

--

[Issue 5115] std.typecons.scoped problems

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #13 from Dmitry Olshansky  ---
Indeed and with `scope` becoming a thing in DIP 1000 we can have our scope
storage class to have stack-allocated classes.

scope a = new Blah(...);

scope class instances are everywhere in DMD frontend now as well.
It's plain as day that our library solution had failed and is not required
anymore.

--

Re: Help me please fix the bug

[Seb via Digitalmars-d]

On Friday, 18 May 2018 at 09:59:27 UTC, Majestio wrote:

On Friday, 18 May 2018 at 06:02:46 UTC, Mike Franklin wrote:

[...]


About dmd-master-2018-05-18 ...

build.sh:
=
#/bin/sh

[...]


FWIW instead of such a build script, you could have used the 
install script which does this for you:


curl https://dlang.org/install.sh | bash -s dmd-nightly

Full docs: https://dlang.org/install

[Issue 5038] Allow declaring class invariant without parentheses

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #8 from Dmitry Olshansky  ---
This compiles today on DMD v2.079.1:

class C {

int height;
int width;

invariant {
assert( height < 10 );
assert( width < 11 );
}
}

--

[Issue 5093] improve error for importing std.c.windows.windows

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #6 from Dmitry Olshansky  ---
This program compiles fine on Ubuntu right now:

---

import std.c.windows.windows;

---

Was fixed years ago when we introduced top-level version per platform in each
file.

--

Re: Help me please fix the bug

[Mike Franklin via Digitalmars-d]

On Friday, 18 May 2018 at 09:35:28 UTC, Majestio wrote:



Also, I believe this is __lambda1:

m_queue = () @trusted { return kqueue(); } ();

Is `kqueue()` nothrow?  You probably need to decorate that 
lambda with `nothrow`.  (i.e. put a `nothrow` right after 
`@trusted`.


Mike


`kqueue()` is not nothrow. From log: "Error: function 
'core.sys.freebsd.sys.event.kqueue' is not nothrow"


This decoration does not solve the problem :(


But you're calling it from a `nothrow` function through a lambda 
that is also not `nothrow`.  Decorate your lambda as `nothrow` 
and then, if you can't make `kqueue()` `nothrow`, put it in a 
try-catch and figure out what to do if it does throw.


m_queue = () @trusted nothrow
{
try
{
return kqueue();
}
catch(Exception ex)
{
// what do you want to do about it?
}
} ();

Mike

Re: auto: useful, annoying or bad practice?

[Chris via Digitalmars-d]

On Thursday, 17 May 2018 at 11:38:13 UTC, Kagamin wrote:


I prefer types spelled as it helps to understand the code. In 
javascript I have to look around to figure out types of 
variables and then I can understand the code. In C# I saw 
surprising abuse like `var id = 0L;` - to think someone would 
go to such length only to insist on type inference.
In part this can be due to unreasonably difficult to spell 
types like ptrdiff_t, so I try to design my code in a way that 
it's easy to spell types.


I was working with Java 8 this week, and God did I miss `auto`. 
And now Java will get `var`[1], t'was about time, indeed! Java 8 
introduced lambdas and functional style features. For lambdas and 
streams the compiler aleady performs automatic type inference (as 
it does for generics, btw). So the next logical step is local 
type inference with `var`. I think that a functional apporach 
(stream().filter().map()...) leads almost automatically to `auto` 
(pardon the pun). Else programming becomes very cumbersome, 
because you have to keep track of the types all the way down the 
chain. That's time better spent somewhere else.


In a way Java has slowly been moving in that direction anyway, 
cf. this answer [2] that reminded me of D's `auto` return type.



[1] http://segasolutionsinc.com/2018/03/30/var-in-java10/
[2] 
https://stackoverflow.com/questions/1348199/what-is-the-difference-between-the-hashmap-and-map-objects-in-java

Re: Help me please fix the bug

[Majestio via Digitalmars-d]

On Friday, 18 May 2018 at 06:02:46 UTC, Mike Franklin wrote:

On Friday, 18 May 2018 at 05:44:12 UTC, Majestio wrote:
I'm curious if you could download one of the nightly compilers 
and test if it is still problem:  
http://nightlies.dlang.org/dmd-master-2018-05-18/


Mike


About dmd-master-2018-05-18 ...

build.sh:
=
#/bin/sh

export PATH=/home/majestio/Projects/dmd2/freebsd/bin64:$PATH
export 
LD_LIBRARY_PATH=/home/majestio/Projects/dmd2/freebsd/lib64:$LD_LIBRARY_PATH


rm -fR ~/.dub
fetch 
http://nightlies.dlang.org/dmd-master-2018-05-18/dmd.master.freebsd-64.tar.xz

tar xf dmd.master.freebsd-64.tar.xz
rm -f dmd.master.freebsd-64.tar.xz
echo -ne '\n\n\n\n\n\n\n' | dub init hello --type=vibe.d
cd hello
dub 2>&1 | tee logfile.log


logfile.log:
=
Fetching libevent 2.0.2+2.0.16 (getting selected version)...
Fetching diet-ng 1.4.5 (getting selected version)...
Fetching taggedalgebraic 0.10.11 (getting selected version)...
Fetching openssl 1.1.6+1.0.1g (getting selected version)...
Fetching botan 1.12.9 (getting selected version)...
Fetching stdx-allocator 2.77.1 (getting selected version)...
Fetching vibe-d 0.8.3 (getting selected version)...
Fetching memutils 0.4.10 (getting selected version)...
Fetching vibe-core 1.4.0 (getting selected version)...
Fetching libasync 0.8.3 (getting selected version)...
Fetching botan-math 1.0.3 (getting selected version)...
Fetching eventcore 0.8.34 (getting selected version)...
Performing "debug" build using 
/usr/home/majestio/Projects/dmd2/freebsd/bin64/dmd for x86_64.

taggedalgebraic 0.10.11: building configuration "library"...
eventcore 0.8.34: building configuration "kqueue"...
stdx-allocator 2.77.1: building configuration "library"...
vibe-core 1.4.0: building configuration "kqueue"...
vibe-d:utils 0.8.3: building configuration "library"...
vibe-d:data 0.8.3: building configuration "library"...
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2518,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2518,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2518,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2518,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2518,25):
 Deprecation: function 
`std.exception.enforceEx!(JSONException).enforceEx!bool.enforceEx` is 
deprecated - Use `enforce`. `enforceEx` will be removed with 2.089.
/home/majestio/.dub/packages/vibe-d-0.8.3/vibe-d/data/vibe/data/json.d(2513,25):
 Deprecation: function 

[Issue 5005] Remove restrictions on module/package with same name.

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |INVALID

--- Comment #7 from Dmitry Olshansky  ---
See package file feature + public imports.

--

[Issue 5004] show both resolved symbols and original identifier in error messages involving aliases

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--

Re: Help me please fix the bug

[Majestio via Digitalmars-d]

On Friday, 18 May 2018 at 07:28:39 UTC, Mike Franklin wrote:

On Friday, 18 May 2018 at 05:44:12 UTC, Majestio wrote:


this()
@safe nothrow {
m_queue = () @trusted { return kqueue(); } ();
m_events.length = 100;
assert(m_queue >= 0, "Failed to create kqueue.");
}




Also, I believe this is __lambda1:

m_queue = () @trusted { return kqueue(); } ();

Is `kqueue()` nothrow?  You probably need to decorate that 
lambda with `nothrow`.  (i.e. put a `nothrow` right after 
`@trusted`.


Mike


`kqueue()` is not nothrow. From log: "Error: function 
'core.sys.freebsd.sys.event.kqueue' is not nothrow"


This decoration does not solve the problem :(

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

[Kagamin via Digitalmars-d]

On Thursday, 17 May 2018 at 19:13:48 UTC, Shachar Shemesh wrote:
The only inherent non @safe thing we advocate here is if you 
want to be able to move const/immutable structs, in which case 
DIP 1014 advocates casting the constness away. That will, of 
course, have to be either @system or @trusted.


There's an idea to give const postblit ability to write, but it's 
difficult to make such exception for operator method, a possible 
syntax can be `this(this, const ref S prev)`

[Issue 4997] names, values, length and basetype enum properties

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #6 from Dmitry Olshansky  ---
Could be easily superseeded by coming introspection DIP

--

[Issue 4970] Failed template instantiations need to propogate

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky  ---
This now works and prints 1234567.

Any better example Jonathan and more specific about actionable intent?

--

Re: Splitting up large dirty file

[Kagamin via Digitalmars-d-learn]

On Thursday, 17 May 2018 at 20:08:09 UTC, Dennis wrote:

```
auto inputStream = (args.length < 2 || args[1] == "-") ? 
stdin : args[1].File;

auto outputFile = new File("output.txt");
foreach (line; inputStream.byLine(KeepTerminator.yes)) 
outputFile.write(line);

```


Do it old school?
---
int line;
auto outputFile = File("output.txt", "wb");
foreach (chunk; inputStream.byChunk(4<<10))
{
  auto rem=chunk;
  while(rem!=null)
  {
auto i=rem.countUntil(10);
auto len=i+1;
if(i<0)len=rem.length; else line++;
outputFile.rawWrite(rem[0..len]);
rem=rem[len..$];
  }
}
---

Re: Of possible interest: fast UTF8 validation

[Nemanja Boric via Digitalmars-d]

On Friday, 18 May 2018 at 08:44:41 UTC, Joakim wrote:


I was surprised to see that adding a emoji to a text message I 
sent last year cut my message character quota in half.  I 
googled why this was and it turns out that when you add an 
emoji, the text messaging client actually changes your message 
encoding from UTF-8 to UTF-16! I don't know if this is a 
limitation of the default Android messaging client, my telco 
carrier, or SMS, but I strongly suspect this is widespread.




Welcome to my world (and probably world of most Europeans) where 
I don't type ć, č, ž and other non-ascii letters since early 
2000s, even though SMS are today mostly flat rate and people chat 
via WhatsApp anyway.

Re: Sealed classes - would you want them in D? (v2)

[Dave Jones via Digitalmars-d]

On Friday, 18 May 2018 at 02:08:47 UTC, KingJoffrey wrote:
On Thursday, 17 May 2018 at 14:14:28 UTC, Steven Schveighoffer 
wrote:


You're welcome to write a DIP, but I don't see a very good 
chance for acceptance given the discussions on this subject.


-Steve


I agree. The D community is too small, and insufficiently 
diverse to discuss this any further.


It's funny how we build programming languages to serve us, but 
we end up serving them.


FFS you're so dramatic. First the world is ending because private 
doesnt work as you expected. Then D is utterly useless without 
the changes you want. Now we live in some dystopian nightmare 
where we are all slaves to the Dlang spec.


Listen up dude, people here have been using D as it is, are happy 
with how it works, and even prefer how it works. They have done 
so for months or years. That is a big bar for you to get over, 
they have years of experience with D working for them. Coming in 
and saying "ooh but thats wrong, your doing it wrong.. because 
OOP... etc..." waving your arms, making hyperbolic statements 
about how its the end of the world etc... wont win any arguments.


You cant convince people of what you say if all you do is give 
them an ideological*** argument that is counter to their years of 
experience. That's just the way it is, it's actually better that 
way, because otherwise people would be swayed by every passing 
preacher and everything would be in a right mess.


***Your argument is ideological because you dont provide any 
evidence for it. This has been pointed out and yet you still dont 
seem grasp it. Saying "this is what you need to do and this is 
why it will benefit" is not evidence, it is a statement of belief.


Please understand I am not saying what you want is right or 
wrong, I'm saying you dont understand why people aren't won over 
by what you say.

[Issue 4894] Cannot use the same name for nested functions even though they're in different scopes

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Dmitry Olshansky  ---
(In reply to Dmitry Olshansky from comment #1)
> Seems like a minor limitation, and getting different mangling


for each of identical signature functions:

void main()
{
{
int nestedFunc(int val)
{
return val+1;
}
}
{
int nestedFunc(int val)
{
return val+2;
}
}
}

--

[Issue 4894] Cannot use the same name for nested functions even though they're in different scopes

[d-bugmail--- via Digitalmars-d-bugs]

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

Dmitry Olshansky  changed:

   What|Removed |Added

   Keywords||bootcamp
 CC||dmitry.o...@gmail.com

--- Comment #1 from Dmitry Olshansky  ---
Seems like a minor limitation, and getting different mangling

--

Re: Of possible interest: fast UTF8 validation

[Joakim via Digitalmars-d]

On Thursday, 17 May 2018 at 23:11:22 UTC, Ethan wrote:
On Thursday, 17 May 2018 at 17:26:04 UTC, Dmitry Olshansky 
wrote:

TCP being  reliable just plain doesn’t cut it. Corruption of
single bit is very real.


Quoting to highlight and agree.

TCP is reliable because it resends dropped packets and delivers 
them in order.


I don't write TCP packets to my long-term storage medium.

UTF as a transportation protocol Unicode is *far* more useful 
than just sending across a network.


The point wasn't that TCP is handling all the errors, it was a 
throwaway example of one other layer of the system, the network 
transport layer, that actually has a checksum that will detect a 
single bitflip, which UTF-8 will not usually detect. I mentioned 
that the filesystem and several other layers have their own such 
error detection, yet you guys crazily latch on to the TCP example 
alone.


On Thursday, 17 May 2018 at 23:16:03 UTC, H. S. Teoh wrote:
On Thu, May 17, 2018 at 07:13:23PM +, Patrick Schluter via 
Digitalmars-d wrote: [...]

- the auto-synchronization and the statelessness are big deals.


Yes.  Imagine if we standardized on a header-based string 
encoding, and we wanted to implement a substring function over 
a string that contains multiple segments of different 
languages. Instead of a cheap slicing over the string, you'd 
need to scan the string or otherwise keep track of which 
segment the start/end of the substring lies in, allocate memory 
to insert headers so that the segments are properly 
interpreted, etc.. It would be an implementational nightmare, 
and an unavoidable performance hit (you'd have to copy data 
every time you take a substring), and the @nogc guys would be 
up in arms.


As we discussed when I first raised this header scheme years ago, 
you're right that slicing could be more expensive, depending on 
whether you chose to allocate a new header for the substring or 
not. The question is whether the optimizations available from 
such a header telling you where all the language substrings are 
in a multi-language string make up for having to expensively 
process the entire UTF-8 string to get that or other data. I 
think it's fairly obvious the design tradeoff of the header would 
beat out UTF-8 for all but a few degenerate cases, but maybe you 
don't see it.


And that's assuming we have a sane header-based encoding for 
strings that contain segments in multiple languages in the 
first place. Linguistic analysis articles, for example, would 
easily contain many such segments within a paragraph, or 
perhaps in the same sentence. How would a header-based encoding 
work for such documents?


It would bloat the header to some extent, but less so than a 
UTF-8 string. You may want to use special header encodings for 
such edge cases too, if you want to maintain the same large 
performance lead over UTF-8 that you'd have for the common case.



Nevermind the recent trend of
liberally sprinkling emojis all over regular text. If every 
emoticon embedded in a string requires splitting the string 
into 3 segments complete with their own headers, I dare not 
imagine what the code that manipulates such strings would look 
like.


Personally, I don't consider emojis worth implementing, :) they 
shouldn't be part of Unicode. But since they are, I'm fairly 
certain header-based text messages with emojis would be 
significantly smaller than using UTF-8/16.


I was surprised to see that adding a emoji to a text message I 
sent last year cut my message character quota in half.  I googled 
why this was and it turns out that when you add an emoji, the 
text messaging client actually changes your message encoding from 
UTF-8 to UTF-16! I don't know if this is a limitation of the 
default Android messaging client, my telco carrier, or SMS, but I 
strongly suspect this is widespread.


Anyway, I can see the arguments about UTF-8 this time around are 
as bad as the first time I raised it five years back, so I'll 
leave this thread here.

WhiteSource supports D

[Andre Pany via Digitalmars-d-announce]

Hi,

I just learned WhiteSource added support for D.

https://www.whitesourcesoftware.com/what-is-whitesource/

Kind regards
André