Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 9:32 PM, Meta wrote:

On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote:

On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:

(D already has a `void` type, so can't use Haskell's word.)


Just so we are all on the same page, from a type-theory perspective void is a 
unit type (it has 1 value), not an uninhabited type (it has no values, i.e. 
Haskell's _|_ (bottom) type).


I read that a Void function in Haskell does not return. Is that incorrect? I'm 
not sure how Void relates to _|_


  https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages

says Haskell does not support empty (i.e. bottom) types.

A function with a return type of unit means "this function returns no useful 
information", because the type only has one possible value anyway. A function 
with a return type of bottom means "this function can never return", because 
there is no value of type bottom that could be returned. All that can be done 
is for the function to diverge (throwing an exception, ending the program, 
looping forever, etc.).


We sort of have this already with `assert(0)`. The compiler knows that no 
execution can take place after an `assert(0)` is encountered (in other words, 
it knows that the function diverges). We just don't have a corresponding type 
to represent this (Rust uses ! but if I remember correctly it's not quite a 
first class type).


If we wanted to be cute we could use `typeof()` to represent this type as 
there is no value you can give to typeof such that it returns the bottom type. 
It also avoids having to come up with some special symbol or name for it.


In C++/D terms, the unit type could be expressed as `enum Unit { unit }` while 
the bottom type would be `enum Bottom {}` (although only conceptually because in 
C++/D you can still do `Bottom b;`).


In D, void is used to signify a function doesn't return a value, but it still 
returns. It also means untyped data, and no initializer.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 9:23 PM, Meta wrote:

On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:

(D already has a `void` type, so can't use Haskell's word.)


Just so we are all on the same page, from a type-theory perspective void is a 
unit type (it has 1 value), not an uninhabited type (it has no values, i.e. 
Haskell's _|_ (bottom) type).


A function with a return type of unit means "this function returns no useful 
information", because the type only has one possible value anyway. A function 
with a return type of bottom means "this function can never return", because 
there is no value of type bottom that could be returned. All that can be done is 
for the function to diverge (throwing an exception, ending the program, looping 
forever, etc.).


Thanks for the explanation.


We sort of have this already with `assert(0)`. The compiler knows that no 
execution can take place after an `assert(0)` is encountered (in other words, it 
knows that the function diverges). We just don't have a corresponding type to 
represent this (Rust uses ! but if I remember correctly it's not quite a first 
class type).


If we wanted to be cute we could use `typeof()` to represent this type as there 
is no value you can give to typeof such that it returns the bottom type. It also 
avoids having to come up with some special symbol or name for it.


That is indeed an interesting idea. Thanks!

(This thread is turning out to be more productive than I anticipated.)

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

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

--- Comment #5 from Cy Schubert  ---
Thanks. I'll develop a patch (will take some time -- I have a number of
projects on the fly at the moment). The patch will will work for FreeBSD 12
after r318736 but break all FreeBSD releases prior to that. This is not
optimal. Is there a version() statement that will allow me to test for FreeBSD
version or can DMD read /usr/include/sys/param.h for the C pre-processor define
of __FreeBSD_version?

Also, it appears that ldc (DMD D with an llvm backend, see
http://wiki.dlang.org/LDC) has the same segfault under FreeBSD 12. I don't
maintain it for the FreeBSD project but it too suffers the same segfault. Maybe
a more holistic approach needs to be taken than a simple point patch.
Eventually when FreeBSD 12 is released to the public there will be two
different stat_t and dirent_t data structures (pre- and post-inode64). What do
you think if DMD D and LDC D provided a facility to test __FreeBSD_version or
if not that the major.minor version number? No matter what we do we will break
old or new systems.

If you can provide a version() statement that can test for either
__FreeBSD_version in /usr/include/sys/param.h (preferred) or the FreeBSD
major.minor version number, any patch I produce will work for both. (I kind of
think this might be useful for most other O/S's too, e.g. RHEL 6 v.s. RHEL 7,
though the test would be very different for each.)

--

[Issue 17625] Confusing error message for private functions in different modules

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 17625] New: Confusing error message for private functions in different modules

[via Digitalmars-d-bugs]

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

  Issue ID: 17625
   Summary: Confusing error message for private functions in
different modules
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

i don't know how to make a clear summary for this, sorry. anyway, here is the
code. let's create three modules:

=== z00.d ===
module z00;
private int boo () { return 42; }

=== z01.d ===
module z01;
private int boo () { return 69; }

=== zmain.d ===
module zmain;
import z00, z01;
void main () { boo(); }


now, do:
dmd -c -o- zmain.d z00.d z01.d

and you'll get:
zmain.d(3): Error: z01.boo at z01.d(2) conflicts with z00.boo at z00.d(2)
zmain.d(3): Error: function z01.boo is not accessible from module zmain

while the second error message gives at least *some* information, the first one
is not only completely useless, but is misleading too: user may think that he
has to rename one of the private functions to get rid of it.

i think that compiler should just say "undefined identifier `boo`", 'cause
visibility rules mandates that private functions are not visible at that point,
and there is no sense in trying to resolve anything there.

--

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/08/2017 05:03 PM, Vladimir Panteleev wrote:

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote:

@disable @property None init();


You meant static here I guess.

The compiler detects (without having anything hardwired about the 
particular type "None") that the type None is impossible to create and 
copy/move from a function, and therefore decrees the function will 
never return.


Cheat: https://is.gd/pf25nP

Works because of NRVO I guess. This particular one is countered by also 
adding a disabled destructor.


Eh, interesting. Indeed this doesn't compile anymore:

struct None
{
@disable this();
@disable this(this);
@disable ~this();
@disable static @property None init();
}

None fun()
{
None none = void;
return none;
}

void main()
{
fun();
}

The type None would then go in object.d.

The compiler detects the pattern and make None implicitly convertible to 
anything so people can write things like:


int x = y ? 100 / y : fun();

Without the conversion, None is a less useful artifact.


Andrei

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/08/2017 10:25 PM, Walter Bright wrote:

On 7/8/2017 7:01 PM, sarn wrote:

On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types that have 
no type (void), I suppose that types that cannot exist will fill out 
the edge cases of the menagerie.


I assume there is a standard jargon for this - does anyone know Type 
Theory?


Are there any other interesting uses for a type that cannot exist?


In pure functional languages, that's what "bottom" or Haskell's Void is.

In Curry–Howard "programs are proofs" theory, a type is a proposition 
and an instance is a proof.  A type with no instance is a proposition 
that can't be proved.


https://codewords.recurse.com/issues/one/type-systems-and-logic

I'm not sure how much impact this has on everyday D programming, but 
hey, it's a thing.


Thanks, it looks like we won't get any help from type theory. We're on 
our own :-)


How does the information provided lead to such a conclusion? There's 
established theory and practice on that.


https://en.wikipedia.org/wiki/Bottom_type

The "Bottom" type (bottom of the type hierarchy lattice) is what's 
needed. If "Object" is the total set i.e. the top of the lattice i.e. 
the type that is so general all types are a subset of it, then "Bottom" 
is the type that is a subtype of all types and is so particular it can't 
be even instantiated. It implicitly converts to everything because it's 
a subtype of everything. Obviously conversion doesn't need to be honored 
because the function never returns.



Andrei

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote:

On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:

(D already has a `void` type, so can't use Haskell's word.)


Just so we are all on the same page, from a type-theory 
perspective void is a unit type (it has 1 value), not an 
uninhabited type (it has no values, i.e. Haskell's _|_ (bottom) 
type).


A function with a return type of unit means "this function 
returns no useful information", because the type only has one 
possible value anyway. A function with a return type of bottom 
means "this function can never return", because there is no 
value of type bottom that could be returned. All that can be 
done is for the function to diverge (throwing an exception, 
ending the program, looping forever, etc.).


We sort of have this already with `assert(0)`. The compiler 
knows that no execution can take place after an `assert(0)` is 
encountered (in other words, it knows that the function 
diverges). We just don't have a corresponding type to represent 
this (Rust uses ! but if I remember correctly it's not quite a 
first class type).


If we wanted to be cute we could use `typeof()` to represent 
this type as there is no value you can give to typeof such that 
it returns the bottom type. It also avoids having to come up 
with some special symbol or name for it.


In C++/D terms, the unit type could be expressed as `enum Unit { 
unit }` while the bottom type would be `enum Bottom {}` (although 
only conceptually because in C++/D you can still do `Bottom b;`).

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
It's easy enough to test!

$ cat test.d 
pragma(mangle, "CeciNestPasUnS")
struct S { }

extern(C++) void fun(S* s);

pragma(msg, fun.mangleof);

$ dmd -o- test.d
_Z3funP1S

Looks like pragma(mangle) has no effect on structs so far.

--

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote:

(D already has a `void` type, so can't use Haskell's word.)


Just so we are all on the same page, from a type-theory 
perspective void is a unit type (it has 1 value), not an 
uninhabited type (it has no values, i.e. Haskell's _|_ (bottom) 
type).


A function with a return type of unit means "this function 
returns no useful information", because the type only has one 
possible value anyway. A function with a return type of bottom 
means "this function can never return", because there is no value 
of type bottom that could be returned. All that can be done is 
for the function to diverge (throwing an exception, ending the 
program, looping forever, etc.).


We sort of have this already with `assert(0)`. The compiler knows 
that no execution can take place after an `assert(0)` is 
encountered (in other words, it knows that the function 
diverges). We just don't have a corresponding type to represent 
this (Rust uses ! but if I remember correctly it's not quite a 
first class type).


If we wanted to be cute we could use `typeof()` to represent this 
type as there is no value you can give to typeof such that it 
returns the bottom type. It also avoids having to come up with 
some special symbol or name for it.

Re: CTFE output is kind of weired

[H. S. Teoh via Digitalmars-d-learn]

On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn 
wrote:
> On 07/08/2017 02:29 PM, Andre Pany wrote:
> 
> > I use assert(false, tmp) to see the content of variable tmp as it
> > seems there is no other way in CTFE.
> 
> A more natural way is pragma(msg), which you can use in main in this
> case:
[...]

Unfortunately, pragma(msg) can only be used *after* CTFE has finished.
It's not possible to print the message *during* CTFE.

Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that
should alleviate this limitation.


T

-- 
There is no gravity. The earth sucks.

[Issue 17624] New: typo in Fields documentation section of https://dlang.org/library/object/exception.html

[via Digitalmars-d-bugs]

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

  Issue ID: 17624
   Summary: typo in Fields documentation section of
https://dlang.org/library/object/exception.html
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: khea...@gmail.com

In the Fields section of https://dlang.org/library/object/exception.html

it says:

file string - The file name and line number of the D source code corresponding
with where the error was thrown from.
...
line ulong  - The file name and line number of the D source code corresponding
with where the error was thrown from.



Believe it should say:

file string - The file name of the D source code corresponding with where the
error was thrown from.
...
line ulong  - The line number of the D source code corresponding with where the
error was thrown from.

--

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Sun, Jul 09, 2017 at 02:01:26AM +, sarn via Digitalmars-d wrote:
> On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
> > We have types that cannot be named (Voldemort types), types that
> > have no type (void), I suppose that types that cannot exist will
> > fill out the edge cases of the menagerie.
> > 
> > I assume there is a standard jargon for this - does anyone know Type
> > Theory?
> > 
> > Are there any other interesting uses for a type that cannot exist?

Technically, the *type* itself exist, it's just that you cannot create
any instances of it. :-P  From the POV of types as sets of possible
values, it's a type that corresponds with an empty set.  However, then
we cannot distinguish between void (which is also by definition a type
that has no instances) and noreturn.  I'm not sure how to interpret
noreturn in this framework... perhaps a set that doesn't exist? :-P  We
could call it a RussellsParadox set. :-D


> In pure functional languages, that's what "bottom" or Haskell's Void
> is.
[...]

Are you sure?  IIRC, it's legal to return bottom; it just signifies that
the value is invalid, and that any operation on it will also result in
bottom.  Sortof like NaN.  That's not the same thing as "this function
never returns".


T

-- 
The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5

Typepinfo is always generated for structs that contain structs that have alias this

[Nicholas Wilson via Digitalmars-d]

Type info is always generated for struct that contain structs 
that have an alias this. This was apparently done because of 
https://issues.dlang.org/show_bug.cgi?id=14948 and "fixed" in 
https://github.com/dlang/dmd/pull/5001 , see also 
https://github.com/dlang/dmd/blob/master/src/ddmd/clone.d#L655 
with the comment bugzilla link.


I have a couple of issues with this approach:
1) it builds typeinfo even if it is not used (the above issue 
involves using such a struct in an AA where it _is_ used, which 
is fine).
2) it does not respect -betterC, so there is no way to not have 
typeinfo which, IMO, makes -betterC rather useless.


Can we be more discerning with generation of typeinfo? i.e. 
generate it lazily and only if used, perhaps with weak linkage so 
end users can have it if they need it?

Re: rdmd vs dmd WRT static constructors

[Andrew Edwards via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote:

On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:

To include stat1.d and stat2.d in the compilation, you'll 
either have to import them in statmain.d or use the 
--extra-file command line switch:


rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d


Okay, got it... thanks Mike.

Re: rdmd vs dmd WRT static constructors

[Mike Parker via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:



$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...


Bug or intended behaviour?



rdmd takes the first D file you give it, follows its import tree, 
and compiles all the modules found there. Anything on the command 
line after the first source file is treated as a command line 
argument to the generated program. So stat1.d and stat2.d are 
never compiled. You'll see if you modify your main function to 
output the args that it will print the file names you passed.


To include stat1.d and stat2.d in the compilation, you'll either 
have to import them in statmain.d or use the --extra-file command 
line switch:


rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d

rdmd vs dmd WRT static constructors

[Andrew Edwards via Digitalmars-d-learn]

RDMD does not behave the same as DMD WRT static constructors. The 
following example, extracted form Mike Parker's "Learning D", 
does not produce the same result:


// stat1.d
module stat1;
import std.stdio;
static this() { writeln("stat1 constructor"); }

// stat2.d
module stat2;
import std.stdio;
static this() { writeln("stat2 constructor"); }

// statmain.d
void main() { }

$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...

$ dmd statmain.d stat1 stat2
$ ./statmain
// outputs...
stat1 constructor
stat2 constructor

Bug or intended behaviour?

Thanks,
Andrew

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 7:01 PM, sarn wrote:

On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types that have no type 
(void), I suppose that types that cannot exist will fill out the edge cases of 
the menagerie.


I assume there is a standard jargon for this - does anyone know Type Theory?

Are there any other interesting uses for a type that cannot exist?


In pure functional languages, that's what "bottom" or Haskell's Void is.

In Curry–Howard "programs are proofs" theory, a type is a proposition and an 
instance is a proof.  A type with no instance is a proposition that can't be 
proved.


https://codewords.recurse.com/issues/one/type-systems-and-logic

I'm not sure how much impact this has on everyday D programming, but hey, it's a 
thing.


Thanks, it looks like we won't get any help from type theory. We're on our own 
:-)

(D already has a `void` type, so can't use Haskell's word.)

Re: proposed @noreturn attribute

[sarn via Digitalmars-d]

On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
We have types that cannot be named (Voldemort types), types 
that have no type (void), I suppose that types that cannot 
exist will fill out the edge cases of the menagerie.


I assume there is a standard jargon for this - does anyone know 
Type Theory?


Are there any other interesting uses for a type that cannot 
exist?


In pure functional languages, that's what "bottom" or Haskell's 
Void is.


In Curry–Howard "programs are proofs" theory, a type is a 
proposition and an instance is a proof.  A type with no instance 
is a proposition that can't be proved.


https://codewords.recurse.com/issues/one/type-systems-and-logic

I'm not sure how much impact this has on everyday D programming, 
but hey, it's a thing.

Re: proposed @noreturn attribute

[crimaniak via Digitalmars-d]

On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote:
I assume there is a standard jargon for this - does anyone know 
Type Theory?
I'm afraid it's perpendicular to type theory - every type 
including Nothing can be returned. Most simple solution - just to 
remove '@' and call this type 'noreturn'.


noreturn functionFoo(bla-bla-bla);

Re: Beta 2.075.0-b2

[Seb via Digitalmars-d-announce]

On Saturday, 8 July 2017 at 23:53:57 UTC, Martin Nowak wrote:

On Friday, 7 July 2017 at 09:27:15 UTC, Paolo Invernizzi wrote:

/Paolo


We've recently changed the versioning of development builds and 
when we bump the hardcoded VERSION file 
https://github.com/dlang/dmd/pull/6935. Looks like we need to 
update that file for every pre-release now to please all the 
external builds that blindly use the VERSION file.
As we want (and might at some point) get rid of that VERSION 
file, builds should already prefer to pass the version 
explicitly (make -f posix.mak VERSION=v2.075.0-b2 RELEASE=1), 
unless they are cloning the repo and can rely on git describe.


Just checking: you are aware that the latest beta (v2.075.0-b2) 
contains a regression in __VERSION__?


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

[Issue 9776] Make raw write mode the default

[via Digitalmars-d-bugs]

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

--- Comment #10 from Nick Sabalausky  ---
As already said before, windows notepad is the *only program that doesn't
handle it (which makes it very *unlike* '/' if indeed "many programs" fail to
deal with properly - which is an exaggeration anyway, but that's beside the
point). If I'm wrong and \n is indeed poorly supported on Windows, then it
should be a simple matter to go ahead and name other examples.

Contrast that to the "\r\r\n" that D code is demonstrably prone to emitting on
Windows, which is handled correctly by little, if anything, on any OS. The
safer behavior is clear, and the consensus of the discussion was the same.

Stubborn clingage to false information and misplaced fears is not befitting of
D.

--

[Issue 17004] std.containers should be usable with @nogc

[via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
This is WIP.
See also: http://dconf.org/2017/talks/staniloiu.html

--

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 4:36 PM, Martin Nowak wrote:
That's a lot more complex (for the compiler and to explain) than using a simple 
magic @noreturn attribute.
Agreed that this is rarely needed but sometimes nice to have. Far from being 
important though ;).


We have types that cannot be named (Voldemort types), types that have no type 
(void), I suppose that types that cannot exist will fill out the edge cases of 
the menagerie.


I assume there is a standard jargon for this - does anyone know Type Theory?

Are there any other interesting uses for a type that cannot exist?

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

--- Comment #6 from Jonathan M Davis  ---
(In reply to greenify from comment #5)
> FYI there will be HttpStatusException soon:
> https://github.com/dlang/phobos/pull/5551

Yeah, but it's not generic. It's derived from std.net.curl.CurlException and
really only makes sense for std.net.curl. It's not something that another
library like vibe.d would use.

--

Re: Beta 2.075.0-b2

[Martin Nowak via Digitalmars-d-announce]

On Friday, 7 July 2017 at 09:27:15 UTC, Paolo Invernizzi wrote:

/Paolo


We've recently changed the versioning of development builds and 
when we bump the hardcoded VERSION file 
https://github.com/dlang/dmd/pull/6935. Looks like we need to 
update that file for every pre-release now to please all the 
external builds that blindly use the VERSION file.
As we want (and might at some point) get rid of that VERSION 
file, builds should already prefer to pass the version explicitly 
(make -f posix.mak VERSION=v2.075.0-b2 RELEASE=1), unless they 
are cloning the repo and can rely on git describe.

Re: proposed @noreturn attribute

[Martin Nowak via Digitalmars-d]

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu 
wrote:

struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}

None ThisFunctionExits();

The compiler detects (without having anything hardwired about 
the particular type "None") that the type None is impossible to 
create and copy/move from a function, and therefore decrees the 
function will never return.


That's a lot more complex (for the compiler and to explain) than 
using a simple magic @noreturn attribute.
Agreed that this is rarely needed but sometimes nice to have. Far 
from being important though ;).

Re: CTFE output is kind of weired

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d-
learn wrote:
> On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
> > app.d(17):called from here: test("1234\x0a5678\x0a")
> >
> > I wrote the source code on windows with a source file with \r\n
> > file endings.
> > But the console output has only the character X0a. In addition
> > not the content of tmp is shown but the full content with the
> > slice information [4..10].
> >
> > Is this the intended behavior?
>
>   The escape sequence says it's hex, and 0a translates to 10, and
> 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of
> it the \r is getting stripped out.
>
>   Funny story as i understand it, \r and \n both have very
> specific meanings to old printers in the old days. \r for
> carriage-Return, and \n for New-line. DOS may have used it, but
> \r more-or-less has no use for newlines and printers today.

It used to matter for terminals as well. With respect to those ancient time,
what Windows does with line endings with \r\n is the most correct, but at
this point, it's just a pointless extra character. AFAIK, no other OS
expects \r\n now. Everything that's *nix-based uses only \n. Unfortunately,
web formats such as http still use \r\n though, because they're based on the
original Internet Message Fomat standard (e-mail really), and it's old
enough that it mattered when it was written.

LOL. As I understand it, the old Macs before Mac OS X actually just used \r,
so twent years ago, depending on your OS, you had to deal with \n, \r, or
\r\n for line endings. Yuck.

>   Curious when using writeln, all newlines seem to have \r
> sequences added. So i suppose it's one of those things that i
> never needed to think about really.

Only if you're on Windows. It's what printf and friends do there too (and
IIRC, writeln still uses printf underneath the hood). C and UNIX pretty much
came into being together, and thus both use \n as the line ending - though
given when they were created, I expect that the distinction between \n and
\r\n still mattered on UNIX systems occasionally. I don't know though. Now
though, no *nix system is going to be doing anything with \r for line
endings.

- Jonathan M Davis

Re: The Nullity Of strings and Its Meaning

[kdevel via Digitalmars-d-learn]

Just saw that my first example was wrong, it should read

  1 void main ()
  2 {
  3import std.uri;
  4string a = "";
  5assert (a);
  6auto s = a.decodeComponent;
  7assert (s);
  8 }

The non-nullity was not preserved. Only the second assert fails.

On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote:

On 07/08/2017 07:16 PM, kdevel wrote:


null is one specific array. It happens to be empty, but that 
doesn't really matter. `foo is null` compares with the null 
array. It doesn't check for emptiness. Conversion to bool also 
compares with null. The concept of emptiness is unrelated.


But why? What is the intended use of converting a string (or any 
other dynamic array) to bool?


In Issue 17623 Vladimir pointed out, that in the case of strings 
there may be a need to store an empty D-string which also is a 
NUL-terminated C-String. It would be sufficient if the ptr-Value 
would convert for checking if there is a valid part of memory 
containing the NUL byte.


Moreover everything I've written about strings is also valid for 
e.g. dynamic arrays of doubles. Here there are also two different 
kinds of empty arrays which compare equal but are not identical. 
I see no purpose for that.


I wonder if this distinction is meaningful and---if not---why 
it is

exposed to the application programmer so prominently.


"Prominently"? It only shows up when you convert to bool.


The conversion to bool (in a bool context) is part of the 
interface of the type. The interface of a type *is* prominently 
exposed.


You only get surprised if you expect that to check for 
emptiness (or something else entirely).


As mentioned I was surprised, that the non-nullity did not pass 
thru decodeComponent.


The spec isn't very clear there. What does "the same array 
elements" mean for empty arrays?


Mathematically that's easily answered: 
https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set


(mkdir)
Using DMD v2.073.2 the first expression terminates the 
programm with a

segmentation fault. With 2.074.1 the program prints

: Bad address
: No such file or directory

I find that a bit confusing.


That looks like a bug/oddity in mkdir. null is as valid a 
string as "". It shouldn't give a worse exception message.


But the message for `""` isn't exactly good, either. Of course 
the directory doesn't exist, yet; I'm trying to create it!


I would expect the same error message (ENOENT) in both cases. The 
EFAULT in
the first case occurs if you invoke POSIX mkdir with NULL as 
first argument.

Re: The Nullity Of strings and Its Meaning

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn 
wrote:
> Yesterday I noticed that std.uri.decodeComponent does not
> 'preserve' the
> nullity of its argument:
>
> 1 void main ()
> 2 {
> 3import std.uri;
> 4string s = null;
> 5assert (s is null);
> 6assert (s.decodeComponent);
> 7 }
>
> The assertion in line 6 fails. This failure gave rise to a more
> general
> investigation on strings. After some research I found that one
> "cannot implicitly convert expression (s) of type string to bool"
> as in
>
> 1 void main ()
> 2 {
> 3string s;
> 4bool b = s;
> 5 }
>
> Nonetheless in certain boolean contexts strings convert to bool
> as here:
>
> 1 void main ()
> 2 {
> 3import std.stdio;
> 4string s; // equivalent to s = null
> 5writeln (s ? true : false);
> 6s = "";
> 7writeln (s ? true : false);
> 8 }
>
> The code prints
>
> false
> true
>
> to the console. This lead me to the insight, that in D there are
> two
> distinct kinds of empty strings: Those having a ptr which is null
> and
> the other. It seems that this ptr nullity not only determines
> whether
> the string compares equal to null in an IdentityExpression [1]
> but also
> the result of the above mentioned conversion in the boolean
> context.
>
> I wonder if this distinction is meaningful and---if not---why it
> is
> exposed to the application programmer so prominently.
>
> Then today I found this piece of code
>
> 1 void main ()
> 2 {
> 3string s = null;
> 4string t = "";
> 5assert (s is t);
> 6 }
>
> which, according to the wording in [1]
>
>"For static and dynamic arrays, identity is defined as
> referring to
> the same array elements and the same number of elements."
>
> shall succeed but its assertion fails [2]. I anticipate the
> implementation compares the ptrs even in the case of zero
> elements.
>
> A last example of 'deviant behavior' I found is this:
>
>  1 import std.stdio;
>  2 import std.file;
>  3 void main ()
>  4 {
>  5string s = null;
>  6try
>  7   mkdir (s);
>  8catch (Exception e)
>  9   e.msg.writeln;
> 10
> 11s = "";
> 12try
> 13   mkdir (s);
> 14catch (Exception e)
> 15   e.msg.writeln;
> 16 }
>
> Using DMD v2.073.2 the first expression terminates the programm
> with a
> segmentation fault. With 2.074.1 the program prints
>
> : Bad address
> : No such file or directory
>
> I find that a bit confusing.
>
> [1] https://dlang.org/spec/expression.html#identity_expressions
> [2] https://issues.dlang.org/show_bug.cgi?id=17623

A dynamic array in D is essentially

struct DynamicArray(T)
{
size_t length;
T* ptr;
}

That's not _exactly_ what it is at the moment (it actually does stuff with
void* rather than templates unfortunately), but essentially, that's what it
is and what it behaves like.

In the case of dyanamic arrays, null is a dynamic array whose ptr is null
and whose length is 0.

The empty property for arrays checks whether the length of the array is 0.
So, any array with a length of 0 (regardless of its ptr) is considered
empty.

The is expression checks for bitwise equality. So,

arr is null

checks for whether the array has a null ptr and a 0 length. In _most_
circumstances, that's equvialent to checking that the array's ptr is null,
but if you do something screwy with unitialized memory, then you could end
up with a ptr value of null and a non-zero length, and

arr is null

would be false. The == expression, on the other, hand checks that the
elements are equal. So, it does something similar to

if(lhs.length != rhs.length)
return false;
for(size_t i = 0; i < lhs.length; ++i)
{
if(lhs.ptr[i] != rhs.ptr[i])
return false;
}
return true;

So, if the lengths are 0, no iterating happens, and the two arrays are
considered equal. This means that a null array is equal to any other empty
array, regardless of the value of ptr. It's also why I would consider

arr == null

to be a code smell. IMHO, if you want to check for empty, then you should
use the empty property or check length directly, since those are clear about
your intent, whereas with

arr == null

you always have the question of whether they should have used an is
expression or whether they were simpy checking for an empty array.

If you understand all of this, it is perfectly possible to write code which
treats null arrays as distinct from empty arrays. However, it's _very_ easy
to get into a situation where you have an empty array rather than a null
one.  Pretty much as soon as you do anything to a null array other than pass
it around or compare it, trusting that it's still null can get error-prone.
And that's why a number of folks think that it's just plain error-prone to
try and treat null arrays as special - but some folks who understand 

Re: Current state of the Garbage Collector

[Ali Çehreli via Digitalmars-d]

Recent thread about this topic:

  http://forum.dlang.org/thread/ewdoqmvslcnypzyrb...@forum.dlang.org

Ali

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 1:20 PM, H. S. Teoh via Digitalmars-d wrote:

Hmmm. Just to clarify, what exactly does @noreturn include? If I have a
function that calls exit(), that's @noreturn? What about a function that
always throws? Or a function that calls exec()? A function that always
ends in assert(0)? A function that context-switches to a different
thread / fibre and terminates this one?


There's no subtlety to it. It's a function that never returns. I.e. it doesn't 
execute a 'RET' instruction.




As for Andrei's idea, it's pretty clever but we would need to
standardize the None type, otherwise we risk hard-to-read code when
everyone rolls their own None type with different names. An attribute
has the advantage that it will be universally understood.


It would be like `size_t`.

Re: CTFE output is kind of weired

[Era Scarecrow via Digitalmars-d-learn]

On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:

app.d(17):called from here: test("1234\x0a5678\x0a")

I wrote the source code on windows with a source file with \r\n 
file endings.
But the console output has only the character X0a. In addition 
not the content of tmp is shown but the full content with the 
slice information [4..10].


Is this the intended behavior?


 The escape sequence says it's hex, and 0a translates to 10, and 
0d is 13; \r\n is usually a 13,10 sequence. So from the looks of 
it the \r is getting stripped out.


 Funny story as i understand it, \r and \n both have very 
specific meanings to old printers in the old days. \r for 
carriage-Return, and \n for New-line. DOS may have used it, but 
\r more-or-less has no use for newlines and printers today.


 Curious when using writeln, all newlines seem to have \r 
sequences added. So i suppose it's one of those things that i 
never needed to think about really.

Re: CTFE output is kind of weired

[Ali Çehreli via Digitalmars-d-learn]

On 07/08/2017 02:29 PM, Andre Pany wrote:

> I use assert(false, tmp) to see the content of variable tmp as it seems
> there is no other way in CTFE.

A more natural way is pragma(msg), which you can use in main in this case:

string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
enum bar = test(foo);
pragma(msg, bar);
}

> The output is kind of weired:
> app.d(6): Error: "1234\x0a5678\x0a"[4..10]
> app.d(17):called from here: test("1234\x0a5678\x0a")

Yes, looks pretty weird. :) I remember issues related to Unicode 
characters, which may be fixed by now, but the [4..10] part is news to me.


Ali

CTFE output is kind of weired

[Andre Pany via Digitalmars-d-learn]

Hi,

I use assert(false, tmp) to see the content of variable tmp as it 
seems there is no other way in CTFE.


The output is kind of weired:
app.d(6): Error: "1234\x0a5678\x0a"[4..10]
app.d(17):called from here: test("1234\x0a5678\x0a")

I wrote the source code on windows with a source file with \r\n 
file endings.

But the console output has only the character X0a.
In addition not the content of tmp is shown but the full content 
with the slice information [4..10].


Is this the intented behavior?

string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
assert(false, tmp);
return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
enum bar = test(foo);
}

Kind regards
André

Re: proposed @noreturn attribute

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 8 July 2017 at 21:03:57 UTC, Vladimir Panteleev 
wrote:
This particular one is countered by also adding a disabled 
destructor.


Oops, never mind that - this makes the function uncallable.

Re: Application settings

[Timothee Cour via Digitalmars-d-learn]

I use protocol buffers (using dproto) for this, storing my settings in
either text or wire format. Advantages: type-safety with fwd/backward
compatibility (unlike json which requires dynamic field access, eg
with dproto you get errors at compile time instead of runtime),
supports comments (although can be done w preprocessor on json config
file), supports more types than json (especially binary without
needing to base64 encode).


On Sat, Jul 8, 2017 at 11:35 AM, Seb via Digitalmars-d-learn
 wrote:
> On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:
>>
>> On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:
>>>
>>> On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:

 On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
>
> [...]


 "best" always depends on your specific use case. I use json files via
 asdf [1]

 [1] https://github.com/tamediadigital/asdf
>>>
>>>
>>>
>>> Seems like quite a heavy package for what I need. I just want to write a
>>> AA to disk and load it, ultimately.
>>
>>
>> Then I would go with INI, because you'll ultimately just have key-value
>> pairs.
>>
>> https://code.dlang.org/packages/baussini (Pretty old but should still work
>> just fine.)
>
>
> There is also inifiled: https://github.com/burner/inifiled (used for
> Dscanner for example)

Re: proposed @noreturn attribute

[Vladimir Panteleev via Digitalmars-d]

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu 
wrote:

@disable @property None init();


You meant static here I guess.

The compiler detects (without having anything hardwired about 
the particular type "None") that the type None is impossible to 
create and copy/move from a function, and therefore decrees the 
function will never return.


Cheat: https://is.gd/pf25nP

Works because of NRVO I guess. This particular one is countered 
by also adding a disabled destructor.

Glibc Enables A Per-Thread Cache For Malloc - Big Performance Win

[Nordlöw via Digitalmars-d]

This is great news:

http://www.phoronix.com/scan.php?page=news_item=glibc-malloc-thread-cache

Faster alternatives to std.xml

[Nordlöw via Digitalmars-d-learn]

What's the fastest XML-parser on code.dlang.org?

Are there any benchmarks that show performance improvements 
compared to std.xml?

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Sat, Jul 08, 2017 at 01:20:03PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Personally, I'm for this. It is useful for functions that constructs
> then throws an exception, for example. It would be nice to be able to
> call such a function from another function that returns non-void
> without having to insert assert(0) into the latter to avoid the
> compiler complaining that you failed to return a value.
> 
> As for Andrei's idea, it's pretty clever but we would need to
> standardize the None type, otherwise we risk hard-to-read code when
> everyone rolls their own None type with different names. An attribute
> has the advantage that it will be universally understood.
[...]

Also, a @noreturn attribute would allow overriding a non-void class
method with a @noreturn one (e.g. the derived class is a sentinel object
that forces an exception / termination upon calling that method),
whereas you can't do that with a None return type because the signature
would not match the base class's.


T

-- 
"Hi." "'Lo."

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Sat, Jul 08, 2017 at 01:09:35PM -0700, Walter Bright via Digitalmars-d wrote:
> On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote:
> > None ThisFunctionExits();
> > 
> > The compiler detects (without having anything hardwired about the
> > particular type "None") that the type None is impossible to create
> > and copy/move from a function, and therefore decrees the function
> > will never return.
> 
> That is a scathingly brilliant idea. It has another nice effect - the
> compiler doesn't have to diagnose:
> 
>@noreturn int foo();
> 
> as an error!
[...]

Hmmm. Just to clarify, what exactly does @noreturn include? If I have a
function that calls exit(), that's @noreturn? What about a function that
always throws? Or a function that calls exec()? A function that always
ends in assert(0)? A function that context-switches to a different
thread / fibre and terminates this one?

Personally, I'm for this. It is useful for functions that constructs
then throws an exception, for example. It would be nice to be able to
call such a function from another function that returns non-void without
having to insert assert(0) into the latter to avoid the compiler
complaining that you failed to return a value.

As for Andrei's idea, it's pretty clever but we would need to
standardize the None type, otherwise we risk hard-to-read code when
everyone rolls their own None type with different names. An attribute
has the advantage that it will be universally understood.


T

-- 
It only takes one twig to burn down a forest.

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
Is it possible to use pragman(mangle) on a struct?

--

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 10:14 AM, Jack Stouffer wrote:

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:

Why should this be an attribute rather than a pragma?


I agree. There's no reason I can think of as to why the no-return should be part 
of the ABI.


Separate compilation. I.e. if one changes the implementation of a function such 
that it now returns, it will break any compiled code that relied on it being 
noreturn.


This is why, for example, nothrow is part of the signature.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote:

None ThisFunctionExits();

The compiler detects (without having anything hardwired about the particular 
type "None") that the type None is impossible to create and copy/move from a 
function, and therefore decrees the function will never return.


That is a scathingly brilliant idea. It has another nice effect - the compiler 
doesn't have to diagnose:


   @noreturn int foo();

as an error!

Me like.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/8/2017 3:52 AM, Nicholas Wilson wrote:
consider that GDC and LDC already both have that attribute courtesy of their 
backends (@attribute("noreturn") and @llvmAttr("noreturn") respectively).


One could argue that since "noreturn" changes the interface of a function, it 
should also change its signature (i.e. name mangling). I don't believe this is 
currently the case with any C++ compiler, or with LDC/GDC.


And frankly I'm sure it's annoying to users to use that attribute portably 
between GDC/LDC. The concept of noreturn should be part of the language, not a 
compiler implementation.

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

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

--- Comment #11 from Nemanja Boric <4bur...@gmail.com> ---
https://github.com/dlang/druntime/pull/1862

--

[Issue 9776] Make raw write mode the default

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #9 from Walter Bright  ---
> unnecessary on all versions of windows

Windows Notepad fails with it.

It's similar to the \ path separator problem on Windows. Many programs,
including lots of Microsoft programs, fail to deal with / properly.

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/1f7e59980539fe0f9ba352b258e8266db6bdff01
fix test coverage

- use single tests as workaround for Issue 16397
- fix single tests (broken sed command)

--

[Issue 17623] Unexpected failure of an assertion on empty strings

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||spec
  Component|dmd |dlang.org
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
This is a documentation bug; the code is correct.

A dynamic array in D is represented as a pointer (.ptr) and a length (.length).

>   string s = null;

s.length is 0 and s.ptr is null.

>   string t = "";

t.length is also 0, but t.ptr points towards a zero-length string literal. The
distinction is mainly that D string literals are zero-terminated, so that they
can be implicitly converted to a C string (const char*).

--

[Issue 17622] inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
Please provide a full self-contained test case, so that we can reproduce the
bug.

--

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/8/17 1:30 PM, Stefan Koch wrote:

On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote:


What is the signature of a function that logs something to a file and 
ends in assert(0)?




I do get your point.
However I still doubt that this is worth a the additional language 
complexity.


Yah, there's marginal utility only - improves code generation and makes 
a few awkward workarounds unnecessary. Yet many other languages and 
implementations have it, so apparently the utility is justifiable.



Usually the clue would be in the name.
sth. like
void logAndDie(string lastWords) { ... }


Problem here being this code is opaque to compile-time analysis and to 
introspection. Unless, that is, the compiler understands the name 
(smell) or the introspection does heuristics on name - e.g. everything 
that ends in "andDie" does not return (smell). -- Andrei

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/8/17 2:26 PM, John Colvin wrote:
I wonder if some lessons from Haskell's "bottom" type would be relevant 
here.


Affirmative. The nice touch of bottom (heh) is that it's convertible to 
anything, so you can use it in complex expressions as a wildcard. -- Andrei

Re: The Nullity Of strings and Its Meaning

[ag0aep6g via Digitalmars-d-learn]

On 07/08/2017 07:16 PM, kdevel wrote:


The assertion in line 6 fails. This failure gave rise to a more general
investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" as in

[...]

Nonetheless in certain boolean contexts strings convert to bool as here:

1 void main ()
2 {
3import std.stdio;
4string s; // equivalent to s = null
5writeln (s ? true : false);
6s = "";
7writeln (s ? true : false);
8 }


Yeah, that's considered "explicit". Also happens with `if (s)`.


The code prints

false
true

to the console. This lead me to the insight, that in D there are two
distinct kinds of empty strings: Those having a ptr which is null and
the other. It seems that this ptr nullity not only determines whether
the string compares equal to null in an IdentityExpression [1] but also
the result of the above mentioned conversion in the boolean context.


Yup. Though I'd say the distinction is null vs every other array, not 
null vs other empty arrays.


null is one specific array. It happens to be empty, but that doesn't 
really matter. `foo is null` compares with the null array. It doesn't 
check for emptiness. Conversion to bool also compares with null. The 
concept of emptiness is unrelated.


Maybe detecting empty arrays would be more useful. As far as I know, 
there's no killer argument either way. Changing it now would break code, 
of course.


Personally, I wouldn't mind if those conversions to bool just went away. 
It's not obvious what exactly is being checked, and it's not hard to be 
explicit about it with .ptr and/or .length. But as Timon notes, that has 
been attempted, and it broke code. So it was reverted, and that's that.



I wonder if this distinction is meaningful and---if not---why it is
exposed to the application programmer so prominently.


"Prominently"? It only shows up when you convert to bool. You only get 
surprised if you expect that to check for emptiness (or something else 
entirely). And you don't really have a reason to expect that. You can 
easily avoid the issue by being more explicit in your code (`arr.ptr is 
null`, `arr.length == 0`/`arr.empty`).



Then today I found this piece of code

1 void main ()
2 {
3string s = null;
4string t = "";
5assert (s is t);
6 }

which, according to the wording in [1]

   "For static and dynamic arrays, identity is defined as referring to
the same array elements and the same number of elements."

shall succeed but its assertion fails [2]. I anticipate the
implementation compares the ptrs even in the case of zero elements.


The spec isn't very clear there. What does "the same array elements" 
mean for empty arrays? Can two arrays refer to "the same array elements" 
but have different lengths? It seems like "referring to the same array 
elements" is supposed to mean "having the same value in .ptr" without 
mentioning .ptr.


The implementation obviously compares .ptr and .length.


A last example of 'deviant behavior' I found is this:

 1 import std.stdio;
 2 import std.file;
 3 void main ()
 4 {
 5string s = null;
 6try
 7   mkdir (s);
 8catch (Exception e)
 9   e.msg.writeln;
10
11s = "";
12try
13   mkdir (s);
14catch (Exception e)
15   e.msg.writeln;
16 }

Using DMD v2.073.2 the first expression terminates the programm with a
segmentation fault. With 2.074.1 the program prints

: Bad address
: No such file or directory

I find that a bit confusing.


That looks like a bug/oddity in mkdir. null is as valid a string as "". 
It shouldn't give a worse exception message.


But the message for `""` isn't exactly good, either. Of course the 
directory doesn't exist, yet; I'm trying to create it!

Re: Application settings

[Seb via Digitalmars-d-learn]

On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:

On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:

On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:

[...]


"best" always depends on your specific use case. I use json 
files via asdf [1]


[1] https://github.com/tamediadigital/asdf



Seems like quite a heavy package for what I need. I just want 
to write a AA to disk and load it, ultimately.


Then I would go with INI, because you'll ultimately just have 
key-value pairs.


https://code.dlang.org/packages/baussini (Pretty old but should 
still work just fine.)


There is also inifiled: https://github.com/burner/inifiled (used 
for Dscanner for example)

Re: proposed @noreturn attribute

[John Colvin via Digitalmars-d]

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu 
wrote:

On 7/8/17 6:15 AM, Walter Bright wrote:
Has anyone a better idea? Does anyone want to write a DIP for 
this?


An attribute is fine. A more PL-minded possibility is to return 
a specific type:


struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}

None ThisFunctionExits();

The compiler detects (without having anything hardwired about 
the particular type "None") that the type None is impossible to 
create and copy/move from a function, and therefore decrees the 
function will never return.



Andrei


I wonder if some lessons from Haskell's "bottom" type would be 
relevant here.

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Nowak  ---
cat > a.d << CODE
module a;
import b;

unittest
{
foo!int();
}
CODE

cat > b.d << CODE
module b;

void foo(T)()
{
return; // line is covered
}

unittest
{
foo!int();
}
CODE

dmd -c -cov -unittest a.d
dmd -c -cov -unittest b.d
dmd -main a.o b.o -ofbug
./bug

cat a.lst b.lst

   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
000|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 50% covered


With different linker order, both calls use the foo instantiation with coverage
instrumentation.

dmd -main b.o a.o -ofbug
./bug

cat a.lst b.lst

   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
  2|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 100% covered
➜  D cat a.lst b.lst   
 20:18:21
   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
  2|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 100% covered


--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

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

--- Comment #10 from Nemanja Boric <4bur...@gmail.com> ---
Ok, I finally got some time to get back to this issue.

There's a sigbus really running, but this is caused by GC, because the runtime
asserts in the shared library finalizers, so it seems that the instance is no
longer there.

I've traced the failing druntime assert (so far, who knows
what else is waiting for us) to this particular commit in rtld.c:

https://github.com/freebsd/freebsd/commit/3ff2e66ecba2094f5c1c1efe7f2d009649527195

So, this is the problem. At the end of the program, fini()s are called for the
shared library and the main executable. Then they call `_do_global_dtors_aux`,
and at that point they will call _d_dso_registry, which will (the problem is
here:) call dlopen (albeit with RTLD_NOLOAD) to obtain the handle for the
object by name.

However, since this particular commit, this doesn't work anymore (and it's
questionable if it should work) - you can't bump a reference count of an object
that's just going to die (dlopen still bumps reference count, even with
RTLD_LOAD passed).

I would guess somehow skipping dlopen calls in this scenario should be figured
out.
Maybe skipping just for the current object, or maybe caching the handles when
first obtained (not sure if they can change on their own; I don't think so, but
still). I'll see to submit a PR tomorrow, now I know where the problem is.

It was quite a ride finding this out. Because first call to dlopen was failing
for the
main executable, so documentation says: "use NULL if you want the main
executable instead", so after doing this - I got it working, so I thought
there's something
special with this path. What's interesting is that my confusion is caused by
the bug
in FreeBSD's code - if the current limitation apply - don't reference "doomed"
object,
one shouldn't be able to work around it by passing NULL. I'll see into sending
a patch there as well.

--

[Issue 5077] std.algorithm.schwartzSort is slow

[via Digitalmars-d-bugs]

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

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #7 from safety0ff.bugz  ---
(In reply to Vladimir Panteleev from comment #6)
> Still reproducible in 2017.
> 
> FWIW, with LDC, the difference is smaller: only schwartzSort is slower than
> regular sort only by about one third rather than being about twice as slow.

Sounds like typical poor performance of using DMD with ranges (i.e.
std.range.zip used by schwartzSwort.)

Possible duplicate of: #14943 & #16120

Aside: Stripping out dynamic stopping policies from std.range.zip led to a few
% improvement on LDC, nothing big though.

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

Summary|test_runner in coverage |missing coverage from
   |mode doesn't match with |template instances when
   |individual test (covers |using separate compilation
   |less)   |

--

Re: The Nullity Of strings and Its Meaning

[Timon Gehr via Digitalmars-d-learn]

On 08.07.2017 19:16, kdevel wrote:


I wonder if this distinction is meaningful


Not nearly as much as it would need to be to justify the current 
behavior. It's mostly a historical accident.



and---if not---why it is
exposed to the application programmer so prominently.


I don't think there is a good reason except backwards-compatibility.
Also see: https://github.com/dlang/dmd/pull/4623
(This is the pull request that restored the bad behaviour after it had 
been fixed.)

Automatic precondition generation (Was: Re: Automatic invariant generation)

[Timon Gehr via Digitalmars-d]

On 07.07.2017 16:17, Jonathan M Davis via Digitalmars-d wrote:

On Friday, July 7, 2017 1:38:13 PM MDT Stefan Koch via Digitalmars-d wrote:

On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer

wrote:

On 7/7/17 4:21 AM, Nicholas Wilson wrote:

The compiler seems to inset an `assert(this !is null, "null
this");` into my struct.
which is for all intents and purposes.
struct Foo {

  Bar b;

}

struct Bar {

  void* ptr;

}


What? When is this invariant called? I've never heard of a
hidden invariant being added to structs, structs are supposed
to be free of such things.

I would call such a thing a bug.

-Steve


It was added because someone VIP demanded it I guess.
you can see the assert being added using -vcg-ast ;)


What does it even do? I don't see how it makes any sense for _anything_ to
have an invariant if it's not explicitly declared.


It is not an implicit invariant, it is an implicit precondition of a 
member function. (The 'this' reference is not part of the state, it is a 
function argument.)




And honestly, I'm of the
opinion that invariants with structs are borderline useless, because they're
run even before opAssign, meaning that if you ever need to use = void;


A struct that has public methods that can accept an uninitialized 
instance does not have an invariant.

That does not mean invariants are useless for structs in general.


or use emplace,


Why would the invariant be called if you use emplace? There are no 
public member functions involved.



then you're screwed if you have an invariant, because it's
bound to fail due to the object not having been initialized previously. > Unfortunately, I couldn't get Walter to agree that it made sense to 

not call

the invariant prior to opAssign being called


It does not always make sense, and when it does make sense, it is not 
limited to opAssign, so maybe we can have an explicit way to disable 
invariant calls for member functions that do not rely on the object 
invariant. (For non-operator overloads there is an obvious workaround: 
just forward to a private member function using UFCS.)



- which is why SysTime no
longer has an invariant (it was blowing up in people's code due to emplace
IIRC).


The only way this can be a problem is if they emplace a state that does 
not satisfy the invariant and then call opAssign. Was your invariant 
satisfied in the init state?



As such, it seems that much more stupid for structs to get any kind
fo invariant automatically.

- Jonathan M Davis



That's not what is happening though.

[Issue 16397] test_runner in coverage mode doesn't match with individual test (covers less)

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
Turns out to be a rather trivial but inherent problem of how coverage and
linkers work.
If a template methods is instantiated in two separately compiled modules (say
std.digest.crc and std.digest.digest) the definition from the first object in
the linker argument order is picked.
Here we have our problem std.digest.digest instantiates WrapperDigest!CRC which
gets emitted with coverage information, but std.digest.crc also instantiates
WrapperDigest!CRC without coverage information (since it's in a foreign module)
the one that gets picked is the latter.

Just like with any other template behavior and -unittest I think dmd should
always emit coverage instrumentation, even if it's for functions in foreign
modules, since eventually any instance might get picked.
This requires to mangle __bcoverage and __coverage and make them linkable from
other modules, at the moment they are private symbols, only accessible from
within a single object file.

The logic that prevents increments of "foreign" modules is here in dmd.
https://github.com/dlang/dmd/blob/ce96c01d271f914cd9acb6100f7fa9f4d494ee8c/src/ddmd/toir.d#L67

--

Re: Release fluent-asserts 0.6.0

[Eric via Digitalmars-d-announce]

On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote:

Hi,

I just made a new release of fluent-asserts:

http://fluentasserts.szabobogdan.com/
https://code.dlang.org/packages/fluent-asserts

Since my last announcement I improved the library with:
 - better error messages
 - better exception api
 - integration with ranges
 - new asserts `executionTime` for callable and `containsOnly`


This is great. It makes writing unit tests much less tedious.

-Eric

Re: proposed @noreturn attribute

[Stefan Koch via Digitalmars-d]

On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu 
wrote:


What is the signature of a function that logs something to a 
file and ends in assert(0)?




I do get your point.
However I still doubt that this is worth a the additional 
language complexity.


Usually the clue would be in the name.
sth. like
void logAndDie(string lastWords) { ... }

[Issue 17621] Don't use deprecated stuff inside Phobos (std/uri.d(338): std.utf.toUTF8) or don't warn the users who are not using it.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #1 from Vladimir Panteleev  ---
This has already been fixed:
https://github.com/dlang/phobos/pull/5409

The fix should be included with 2.075.0.

--

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/08/2017 01:14 PM, Jack Stouffer wrote:

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:

Why should this be an attribute rather than a pragma?


I agree. There's no reason I can think of as to why the no-return should 
be part of the ABI.


If present in the signature of the function you can figure that the 
function won't return by introspection. -- Andrei

The Nullity Of strings and Its Meaning

[kdevel via Digitalmars-d-learn]

Yesterday I noticed that std.uri.decodeComponent does not 
'preserve' the

nullity of its argument:

   1 void main ()
   2 {
   3import std.uri;
   4string s = null;
   5assert (s is null);
   6assert (s.decodeComponent);
   7 }

The assertion in line 6 fails. This failure gave rise to a more 
general

investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" 
as in


   1 void main ()
   2 {
   3string s;
   4bool b = s;
   5 }

Nonetheless in certain boolean contexts strings convert to bool 
as here:


   1 void main ()
   2 {
   3import std.stdio;
   4string s; // equivalent to s = null
   5writeln (s ? true : false);
   6s = "";
   7writeln (s ? true : false);
   8 }

The code prints

   false
   true

to the console. This lead me to the insight, that in D there are 
two
distinct kinds of empty strings: Those having a ptr which is null 
and
the other. It seems that this ptr nullity not only determines 
whether
the string compares equal to null in an IdentityExpression [1] 
but also
the result of the above mentioned conversion in the boolean 
context.


I wonder if this distinction is meaningful and---if not---why it 
is

exposed to the application programmer so prominently.

Then today I found this piece of code

   1 void main ()
   2 {
   3string s = null;
   4string t = "";
   5assert (s is t);
   6 }

which, according to the wording in [1]

  "For static and dynamic arrays, identity is defined as 
referring to

   the same array elements and the same number of elements."

shall succeed but its assertion fails [2]. I anticipate the
implementation compares the ptrs even in the case of zero 
elements.


A last example of 'deviant behavior' I found is this:

1 import std.stdio;
2 import std.file;
3 void main ()
4 {
5string s = null;
6try
7   mkdir (s);
8catch (Exception e)
9   e.msg.writeln;
   10
   11s = "";
   12try
   13   mkdir (s);
   14catch (Exception e)
   15   e.msg.writeln;
   16 }

Using DMD v2.073.2 the first expression terminates the programm 
with a

segmentation fault. With 2.074.1 the program prints

   : Bad address
   : No such file or directory

I find that a bit confusing.

[1] https://dlang.org/spec/expression.html#identity_expressions
[2] https://issues.dlang.org/show_bug.cgi?id=17623

Re: proposed @noreturn attribute

[Jack Stouffer via Digitalmars-d]

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote:

Why should this be an attribute rather than a pragma?


I agree. There's no reason I can think of as to why the no-return 
should be part of the ABI.

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/08/2017 08:20 AM, Stefan Koch wrote:
... since it's going to be special cased by the compiler we might as 
well hardwire a type called none.


Walter and I have repeated experience with moving compiler smarts into 
library artifacts. Sometimes it's arguably not the best way to go, but 
in the majority of cases it's been beneficial for both the language and 
the compiler implementation.



Although it seems to be that the scope of no-return is extremely narrow.
Because we do have precisely builtin assert(0).


What is the signature of a function that logs something to a file and 
ends in assert(0)?



Andrei

[Issue 17556] std.json encodes non-BMP characters incorrectly with JSONOptions.escapeNonAsciiChars

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/941e2936b6c90fce0b11eada9605c231ca498e9f
Fix Issue 17556 - std.json encodes non-BMP characters incorrectly with
JSONOptions.escapeNonAsciiChars

--

[Issue 5904] std.json parseString doesn't handle chars outside the BMP

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b23e7a4107cc2eb3275e022cb46f7270e586ca29
Fix Issue 5904 - std.json parseString doesn't handle chars outside the BMP

--

[Issue 17555] [REG2.070.0] Control characters in JSON data are invalid and should cause an exception

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/55aa34e4407cd24a29f5e271a3fa318d56acf487
Fix Issue 17555 - [REG2.070.0] Control characters in JSON data are invalid and
should cause an exception

--

[Issue 17623] New: Unexpected failure of an assertion on empty strings

[via Digitalmars-d-bugs]

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

  Issue ID: 17623
   Summary: Unexpected failure of an assertion on empty strings
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

According to the documentation [1]:

   "For static and dynamic arrays, identity is defined as referring to
the same array elements and the same number of elements."

this code

   $ cat stringidentity.d 
   void main ()
   {
  string s = null;
  string t = "";
  assert (s is t);
   }

shall pass but the assertion fails

   $ ./stringidentity
   core.exception.AssertError@stringidentity.d(5): Assertion failure

[1] https://dlang.org/spec/expression.html#identity_expressions

--

[Issue 17564] std.experimental.allocator.theAllocator is null within shared static this

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/4a5d2b3b189f072e9bd0b1779a7d585e3945921b
Fix issue 17564: Eliminate "static this" for theAllocator

https://github.com/dlang/phobos/commit/2e0a49cd397ea1bdb993e3a9271193cf6051b8ce
Merge pull request #5519 from s-ludwig/lazy_the_allocator

--

[Issue 17557] std.json should not do UTF decoding when parsing

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/226f8e001c256836bdcc7917443704db93f318c3
Fix Issue 17557 - std.json should not do UTF decoding when parsing

--

[Issue 17553] std.json should not do UTF decoding when encoding JSON

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/5031ff1446f58a4a76e16d76aa80329d1981cb32
Fix Issue 17553 - std.json should not do UTF decoding when encoding JSON

--

[Issue 17622] inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

steven kladitis  changed:

   What|Removed |Added

   Keywords||dll

--- Comment #1 from steven kladitis  ---
when using -inline in 64 bit mode all apps I have the goto the web do not work.
-m64 -inline 
on windows 10 64 bit
Windows comes back with a message about debugging the app.
Without -inline they work.

compiler --> DMD32 D Compiler 2.075.0-b2

--

[Issue 17622] New: inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

  Issue ID: 17622
   Summary: inline  for m64 fails web APPS
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: steven_kladi...@yahoo.com

--

Re: D for mobile development

[Ecstatic Coder via Digitalmars-d]

IMHO, the curent D language and standard libraries are fine 
enough, and instead of investing time in tweaking them, making 
this GUI library and the required tool chain fully operational 
on desktop and mobile platform should be the #1 priority.


This is a community-driven OSS project, there is no #1 
priority.  You may want that, but many others may not care for 
it, and you can't make them volunteer to do it.


Indeed.

But that doesn't mean that I'm completely wrong in thinking that 
a language which is natively very convenient for web and mobile 
development (like Dart) can easily increase its popularity.


Because as long as developing cross-platform connected mobile 
apps and backends is significantly EASIER with other languages 
(and I'm not only talking about Dart), it will be very hard 
for D to somewhat improve its popularity.


D compares more to the C/C++ NDK, which isn't in the same 
league of ease of use and integration as you talk about with 
Dart. But D could also be used for more lightweight GUI app 
development, so we'd like to get it to the usability level of 
Dart someday.


That's right, but I still think that D, as a language, has 
everything needed to make it the perfect language for mobile, 
server and desktop applications.


D is as convenient as a high-level scripting language, and in the 
mean time as fast and powerful as a low-level programming 
language like C++.


That's the ideal mix for mobile applications. And nowadays MANY 
programmers are developing connected and mobile applications.


And this is actually the #1 reason why I can't convince ANY of 
the developers I know to even try the language...


Are you talking about the ease of GUI development or mobile or 
both holding D back?  I agree that D has neglected mobile, see 
my recent thread:


http://forum.dlang.org/thread/xgiwhblmkvcgnsktj...@forum.dlang.org


+1

Re: Go Your Own Way (Part One: The Stack)

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 9:51 PM, Mike Parker wrote:

On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote:

On 7/7/2017 4:35 PM, Nicholas Wilson wrote:
It's an intrinsic in LDC. We can certainly drop the per platform and 
move to a per compiler definition instead.


It's already there under:

version (DigitalMars)


I read this as CRuntime_DigitalMars, which prompted a search that led me 
to a page at MSDN on _alloca, which gave me a compiler error when I 
prototyped it, which led to my prototyping alloca for CRuntime_Microsoft 
and finding success, which has now confirmed my worry that publishing 
without a review was a bad idea. I've updated the post. Thanks!


Ha! as someone who doesn't regularly develop on Windows, I didn't even test.

I should have known better, as I've used alloca in druntime, and that 
wouldn't work if it didn't build on Win64.


-Steve

Re: All asserts need to have messages attached! Explicit as possible!

[Seb via Digitalmars-d]

On Saturday, 8 July 2017 at 01:31:54 UTC, Seb wrote:
On Saturday, 8 July 2017 at 01:01:38 UTC, Vladimir Panteleev 
wrote:

On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote:

It would be easy to find all the bad asserts?


Does Dscanner have a rule to detect assert and enforce calls 
without a message? We should have it enabled for Phobos.


No, but now there's: 
https://github.com/dlang-community/D-Scanner/pull/495
I can always add this to the phobos branch at DScanner if you 
want to test this immediately.


We can improve the status quo:

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

Once this is integrated, everyone can help out and improve Phobos 
by just removing a single module from the blacklist - it's a PR 
away.

problem overloading functions with complex enum type

[Eric via Digitalmars-d-learn]

import std.stdio;

enum A : int { a, b };
enum B : int { a, b };
enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
enum BS : string[2] { a = ["5","6"], b = ["7","8"] };

void func(A a)   { writeln("A");  }
void func(B b)   { writeln("B");  }
void funcs(AS a) { writeln("AS"); }
void funcs(BS b) { writeln("BS"); }

void test()
{
func(A.a); // no compiler error
funcs(AS.a); // compiler error: matches both funcs(AS) and 
funcs(BS)

}

void main(string[] args) { }

In the above code, the function with the simple enum type 
argument can
be overloaded, but the function with the complex enum type 
argument cannot be overloaded.

Is this a bug?

Thx.
Eric

[Issue 17621] New: Don't use deprecated stuff inside Phobos (std/uri.d(338): std.utf.toUTF8) or don't warn the users who are not using it.

[via Digitalmars-d-bugs]

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

  Issue ID: 17621
   Summary: Don't use deprecated stuff inside Phobos
(std/uri.d(338): std.utf.toUTF8) or don't warn the
users who are not using it.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

$ cat toutf8warning.d
void main ()
{
   import std.uri;
   "".decodeComponent;
}
$ dmd toutf8warning 
[redacted]/dmd2/linux/bin64/../../src/phobos/std/uri.d(338): Deprecation:
function std.utf.toUTF8 is deprecated - To be removed November 2017. Please use
std.utf.encode instead.
$ dmd --version
DMD64 D Compiler v2.074.1
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

--

Re: proposed @noreturn attribute

[Jonathan Marler via Digitalmars-d]

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:
C compilers (and by extension C++ compilers) usually have an 
extension which allows a function to be marked as one that 
never returns. The point of this is it enables improved data 
flow analysis and better code being generated.


Noreturn functions crop up in things like assert's and 
enforce's. DMD internally hardcodes a few functions it knows 
about that are noreturn, and the DMD optimizer and codegen take 
advantage of it.


But when people write their own assert's and enforce's, this 
falls apart. While the programs will still work, they won't be 
as efficient as they could be.


Having an @noreturn attribute will take care of that:

   @noreturn void ThisFunctionExits();

Yes, it's another builtin attribute and attributes are arguably 
a failure in language design.


Has anyone a better idea? Does anyone want to write a DIP for 
this?


Example:

DMC uses a pragma to do it:

void ThisFunctionExits();
#pragma noreturn(ThisFunctionExits);

GCC uses an attribute:

void ThisFunctionExits() __attribute__ ((__noreturn__));

VC uses:

__declspec(noreturn) void ThisFunctionExits();


Some questions...

What kinds of control flow does this apply to?  My guess is that 
you consider a function to be "no-return" so long as it never 
returns control directly back to the caller.  The examples I can 
think of would be functions that prevent returning to the caller 
by calling exit, asserting, throwing or even just executing an 
infinite loop (expecting the program to exit via signal or some 
other means).  Is this right?


Another question I had was would the compiler provide control 
flow checking to make sure that the function does not return?


Also, I can imagine some optimizations that can be done with this 
information, would you mind sharing the optimization(s) you had 
in mind?

Re: proposed @noreturn attribute

[bachmeier via Digitalmars-d]

On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu 
wrote:

On 7/8/17 7:07 AM, bachmeier wrote:

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:


Having an @noreturn attribute will take care of that:

   @noreturn void ThisFunctionExits();


Why should this be an attribute rather than a pragma?


So it's part of the summary of the function. -- Andrei


But it's additional clutter being added for the benefit of the 
compiler. Additions like this make it hard for those of us 
showing the language to others.

[Issue 7063] No error or warning for conflicting D and C symbols

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Hardware|x86 |All

--

Current state of the Garbage Collector

[helxi via Digitalmars-d]

First off, let me admit that I am no expert on Garbage 
Collector Technology or Language implementation. I made this 
thread only to know if there is any attempt being done to improve 
the current GC's efficiency.


As the Garbage Collection techniques are becoming more 
efficient, how is D keeping up with the competition?


As far as I understand, our GC is not the smartest one out 
there which can be a serious bottleneck to the overall 
performance. D doesn't have an incremental GC (let alone a 
generational one afaik), and the (fully conservative, 
stop-the-world) one it has just isn't very "good". So D sometimes 
would force me to revert to manual memory management, which I 
have no interest in whatsoever.


If you look at Nim, it has a nice thread local GC, it's 
claimed to be faster in theory. (I have a feeling it will pose 
problems if you want to go multi-threaded).

Re: proposed @noreturn attribute

[Stefan Koch via Digitalmars-d]

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu 
wrote:

On 7/8/17 6:15 AM, Walter Bright wrote:
Has anyone a better idea? Does anyone want to write a DIP for 
this?


An attribute is fine. A more PL-minded possibility is to return 
a specific type:


struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}

None ThisFunctionExits();

The compiler detects (without having anything hardwired about 
the particular type "None") that the type None is impossible to 
create and copy/move from a function, and therefore decrees the 
function will never return.



Andrei


... since it's going to be special cased by the compiler we might 
as well hardwire a type called none.
Although it seems to be that the scope of no-return is extremely 
narrow.

Because we do have precisely builtin assert(0).

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/8/17 7:07 AM, bachmeier wrote:

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:


Having an @noreturn attribute will take care of that:

   @noreturn void ThisFunctionExits();


Why should this be an attribute rather than a pragma?


So it's part of the summary of the function. -- Andrei

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 7/8/17 6:15 AM, Walter Bright wrote:

Has anyone a better idea? Does anyone want to write a DIP for this?


An attribute is fine. A more PL-minded possibility is to return a 
specific type:


struct None
{
@disable this();
@disable this(this);
@disable @property None init();
}

None ThisFunctionExits();

The compiler detects (without having anything hardwired about the 
particular type "None") that the type None is impossible to create and 
copy/move from a function, and therefore decrees the function will never 
return.



Andrei

[Issue 17620] dwarfeh(327) fatal error

[via Digitalmars-d-bugs]

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

Sönke Ludwig  changed:

   What|Removed |Added

 CC||slud...@outerproduct.org

--- Comment #1 from Sönke Ludwig  ---
Small correction: It happens in the vibe.d based reverse proxy that sits in
front of the registry process.

It seems to happen occasionally when the SSL stream throws an exception due to
some protocol error (this is the only exception that happens during normal
operation). I will try again to prepare a test case, although that has proven
difficult in the past.

--

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

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

--- Comment #4 from Etienne  ---
I still get this infinite loop problem every now and then. I got around it by
auto-launching more processes and killing them every hour, it seems like it
happens when my (very busy) application starts to throw more frequently. It
became 99% less frequent after putting a loop counter in this code

auto eh = ExceptionHeader.toExceptionHeader(exceptionObject);
int infini_guard;
while (eh.next && ++infini_guard < 1)
{
ExceptionHeader* ehn = eh.next;

--

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #5 from greenify  ---
FYI there will be HttpStatusException soon:
https://github.com/dlang/phobos/pull/5551

--

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||EH
 CC||c...@dawg.eu

--- Comment #3 from Martin Nowak  ---
We got a similar report for dub-registry (not using botan I assume).

--

[Issue 17620] New: dwarfeh(327) fatal error

[via Digitalmars-d-bugs]

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

  Issue ID: 17620
   Summary: dwarfeh(327) fatal error
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Keywords: EH
  Severity: major
  Priority: P3
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

We have reports that dub-registry as of it's current version [¹] is constantly
crashing with "dwarfeh(327) fatal error". Occasionally it hangs in a busy loop
which sounds like a duplicate of issue 16641.

[¹]:
https://github.com/dlang/dub-registry/commit/e7c1868566888e6b29f570cb5731b9bf56e790c9
[²]:
https://github.com/dlang/druntime/blob/0d1fa213b492ef2e236769e4fd634ba9d38b4fc1/src/rt/dwarfeh.d#L327

--

[Issue 17271] dwarfeh(224) fatal error

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||EH
   Priority|P1  |P3
   Hardware|x86 |All
   Severity|enhancement |major

--

[Issue 17271] dwarfeh(224) fatal error

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
 OS|Windows |All

--- Comment #2 from Martin Nowak  ---
Might have been affected by https://github.com/dlang/druntime/pull/1673, at
least what previously was an error should now print the exception before
terminating.
Could you please recheck

--

Re: proposed @noreturn attribute

[bachmeier via Digitalmars-d]

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote:


Having an @noreturn attribute will take care of that:

   @noreturn void ThisFunctionExits();


Why should this be an attribute rather than a pragma? It looks to 
me that the goal is to pass information to the compiler, and 
according to the spec:


"Pragmas are a way to pass special information to the compiler 
and to add vendor specific extensions to D. Pragmas can be used 
by themselves terminated with a ‘;’, they can influence a 
statement, a block of statements, a declaration, or a block of 
declarations."

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
I think the only good idea from bearophile's list is OverflowException, as
conversion data often comes from user input, and it may be useful to
distinguish values that are syntactically correct but simply too large to be
represented in the program's chosen data type, from values that are
syntactically incorrect.

--