Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

 On 07/09/2017 09:21 PM, Nick Sabalausky wrote:
>
> Ah, I guess it is very similar after all, except it'd be based on top of
> and coexist with all of D's design by introspection stuff (rather than
> exist without it as with C++), thus avoiding a lot of the downsides and
> getting best of both worlds.

Ha ha, I still feel more than a little silly for pitching what amounts 
to contracts as "an out-there idea I've been mulling over", but indulge 
in a little (partially-baked) taste to show this at least has some merit 
anyway. Hell, call it "concepts++" or "concepts, the D way" (note: I'm 
NOT pitching this as a suggestion for something D should do. Not saying 
D should or should'nt, just speaking purely in the realm of "langauge 
design brainstorming" here...Just because it's been on my mind and the 
"Why is phobos so wack?" thread brought some relevence)


Behold! The power of combining constraints/design-by-introspection 
*with* concepts:


Current declaration of std.array.join:

---
ElementEncodingType!(ElementType!RoR)[] join(RoR, R)(RoR ror, scope R sep)
if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && 
isInputRange!R && is(Unqual!(ElementType!(ElementType!RoR)) == 
Unqual!(ElementType!R)));


ElementEncodingType!(ElementType!RoR)[] join(RoR, E)(RoR ror, scope E sep)
if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)) && is(E 
: ElementType!(ElementType!RoR)));


ElementEncodingType!(ElementType!RoR)[] join(RoR)(RoR ror)
if (isInputRange!RoR && isInputRange!(Unqual!(ElementType!RoR)));
---

(ie, completely incomprehensible at-a-glance)

Just one possibility of an entirely hypothetical D++ (assuming I'm even 
interpreting the D version correctly):


---
// Note: This assumes the "ElementEncodingType vs ElementType" distinction
// is nothing but a colossal mistake caused purely by the existance of
// auto-decoding, which was (as an assumption this psuedo-code is predicated
// upon) a complete clusterf*** of misdesign (Ie, *such* a huge stretch of
// the imagination ;)), which in this hypothetical ideal langauge has
// been killed dead with nuclear fire, and then beaten some more with
// spiked crowbars, just to be sure.

/++
  Params:
ror: an input range (or better) of input ranges (or better) of
 any type (shorthand for 'InputRange!InputRange!Type')
sep: a separator that can be any input range ('InputRange!Type').
  Returns: Shorthand for 'InputRange!Type': Ie, an input range (or better).
  Note: This is implicitly templated on typeof(ror) and typeof(sep).
+/
InputRange join(InputRange!InputRange ror, InputRange sep)
  // Relationship constraints:
  if(UnqualTypeMatch!(ror, sep, return))

/++
  Like above, but sep is 'Type' instead of 'InputRange!Type'.
  Since 'Type' is less specific than 'InputRange!Type', the prior overload
  is preferred.
+/
InputRange join(InputRange!InputRange ror, Type sep)
  // Relationship constraints:
  if(unqualTypeMatch!(ror, InputRange!sep, return))

// No separator
InputRange join(InputRange!InputRange ror)
  // Relationship constraints:
  if(unqualTypeMatch!(ror, return))

// Extra-special specialization:
// Why multiple if() allowed? Because it makes the formatting less
// of a mess, thus better readability. Good enough reason to me!
InputRange join(InputRange!InputRange ror, Type sep)
  if(unqualTypeMatch!(ror, sep, return))
  if(hasLength!typeof(sep))
  {  /+...take advantage of sep.length...+/ }

// Note: Those constraints have further room for syntactical improvement.
---

That example involves some additional things defined by the
stdlib (*extremely* hypothetical syntax):

---
concept InputRange(Element)
{
this()
{
// Current body of isInputRange here
}

// Most of isInputRange can *optionally* be replaced with:
Element front();
void popFront();
bool empty();
}

concept ForwardRange : InputRange // Builds upon InputRange
{
// Author can opt to do this (more powerful):
this()
{
super.this();
typeof(this) x = this.save;
}

// Or this (more succinct):
ForwardRange save();
}

// *Anything*: A concrete (instatiable) type, or a templated
// stand-in for a type (ie "T"), or an alias, or nothing at all.
// Types *themselves* are first-class types! But implemented as
// templates, rather than as runtime-OO.
algebraic Any : Bottom;

// An actual concrete type
algrbraic Type : Any
if(isType!this);

// An actual concrete type?
bool isType(Any any) {/+...introspection magic lies here...+/}

// This is implicitly a template.
bool unqualTypeMatch(InputRange!Any args...)
{
return args.map!(GetType).map!(Unqual).equal;
}

// If any is a static type, return any.
// If any is a value, return typeof(any)
// This is 

[Issue 17629] package.di files cannot be used

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/e205f8947bfb099dd12556cc5c3343cdee479eae
fix Issue 17629: Try loading package.di prior to package.d

* This is the same behavior as ordinary modules where .di files are scanned
first

https://github.com/dlang/dmd/commit/0bd1739fdd8b87e57f4886555f27a8e07e98c643
add test for Issue 17629 - package.di files not supported

--

[Issue 17629] package.di files cannot be used

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: How to get the address of a static struct?

[Era Scarecrow via Digitalmars-d-learn]

On Monday, 10 July 2017 at 03:48:17 UTC, FoxyBrown wrote:

static struct S

auto s =  // ?!?!?! invalid because S is a struct, but...

basically s = S. So S.x = s.x and s.a = S.a;

Why do I have to do this?


 Static has a different meaning for struct. More or less it means 
it won't have access to a delegate/fat pointer to the function 
that uses it. It doesn't mean there's only 1 instantiation ever 
(unlike like the static variables). So static is a no-op in this 
case (though still syntactically legal to use).


 To get the address of the struct you STILL have to instantiate 
it first. Although you don't to in order to access it's static 
members.


 Though if all the members are static, it's basically a namespace 
and doing so is kinda pointless.

[Issue 17482] [REG 2.074] comile error: Comparing Nullable!Variant with basic type

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/a7ea880eb24a36e09e50de7b8b32d941110aa630
Fix issue 17482: Fix Nullable!Variant equality checks.

https://github.com/dlang/phobos/commit/d07b10148dcfbf494a8f433ebf5646a4cb8d1b10
Merge pull request #5541 from jmdavis/issue_17482

--

Re: proposed @noreturn attribute

[Nicholas Wilson via Digitalmars-d]

On Monday, 10 July 2017 at 03:25:26 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 07/09/2017 05:14 PM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu 
via Digitalmars-d wrote:

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
It's no more of a hack than leaving assert(0) in release 
code.


I wouldn't argue that. I do argue it's a hack compared to the
principled solution of a bottom type. -- Andrei


I like out{ assert(0); } for pretty much the same reasons as 
Steven
lists. The biggest pro is that **the language already supports 
it*.
Contract syntax already is meant to signal intent, and 
assert(0) signals
"never gets here". You can't find a better solution than this. 
All the
other alternatives require adding even more baggage to an 
already
heavy language, or compiler voodoo to recognize a particular 
pattern of
defining a type.  I'd say out{assert(0);} is the principled 
solution --
expressing something the current language can already express, 
and it's

the other alternatives that are "exotic".



Prioritizing "path of least resistense" over "this is cleaner 
and more principled" is the hallmark of C++-style langauge 
design. Please, please, please, let's stay away from that path.


While I agree with your sentiment in principle (heh), we need to 
keep in mind it purpose.

So far I count four requirements of a solution:
documentation
optimisation
ability to statically reflect upon
ability to implement

Of the approached listed only out{assert(0);} fails the static 
reflection check.

Which leaves
1)@noreturn
2)@disable(return)
3)none

1 & 2 are almost functionally identical in their implementation 
with 2 requiring some semantic hacks to the compiler and 
precludes the AliasSeq approach below, so I consider 1 to be 
superior to 2.


this leaves 1 & 3.

w.r.t documentation for 1 this is a solved problem, it becomes 
part of the type signature and will be picked up in the 
documentation building tools. 3 it becomes part of the return 
type and can also be solved by documenting the type.


w.r.t optimisation assuming both 1 & 3  impact DMD equally then 
there is no difference except that:


Implementation: 3 would require GDC and LDC to make changes _when 
they already have a solution_. It would also be _considerably 
more work_ than 1, and would be _backwards incompatible_ with 
older compilers. In fact 1 could be implemented _Immediately_ for 
GDC and LDC by having


enum __noreturn;
version (DigitalMars) alias noreturn = __noreturn;
else version(GNU) {
import gcc.attributes : attribute;
alias noreturn = AliasSeq!(__noreturn,attribute("noreturn"));
}
else version (LDC)
{
import ldc.attributes : llvmAttr;
alias noreturn = AliasSeq!(__noreturn,llvmAttr("noreturn"));
}

and reflect upon the presence of __noreturn;

I am strongly against the need to complicate the compiler when an 
equal (IMHO better) solution _already exists_, for extremely 
marginal gain: anyone seriously concerned about the small 
optimisation benefit will already be using GDC or LDC, the 
applicability of noreturn is minuscule, AFAICT C's _exit and an 
unconditional throw (Exception or Error) are the only functions 
for which it applies.

Re: How to get the address of a static struct?

[rikki cattermole via Digitalmars-d-learn]

Thread local struct:

```D
module foobar;

struct Foo {
int x;
}

Foo foo = Foo(8);

void main() {
import std.stdio;
writeln();
}
```

Global struct:

```D
module foobar;

struct Foo {
int x;
}

__gshared Foo foo = Foo(8);

void main() {
import std.stdio;
writeln();
}
```

Compile time constant:

```D
module foobar;

struct Foo {
int x;
}

enum FOO = Foo(8);

void main() {
import std.stdio;
Foo foo = FOO;
writeln();
}
```

[Issue 16577] A selective import on a symbol that has overloads leads to duplicate messages

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

Summary|deduplicate deprecation |A selective import on a
   |messages|symbol that has overloads
   ||leads to duplicate messages

--

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/09/2017 09:51 PM, 12345swordy wrote:


No responses!?


FWIW, traffic on this NG tends to slow down on the weekends. I've long 
wondered if most of the activity here is when people need a break during 
their workday ;)

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/5774d017eb4fa154491385a91f590abc2f66b964
Fix issue 16191 - std/digest/digest.d should be renamed to package.d

--

How to get the address of a static struct?

[FoxyBrown via Digitalmars-d-learn]

static struct S
{
   public static:
int x;
string a;
}





auto s =  // ?!?!?! invalid because S is a struct, but...


basically s = S. So S.x = s.x and s.a = S.a;

Why do I have to do this?

Because in visual D, global structs don't show up in the 
debugger. So if I create a local alias, I can see see them, but I 
don't wanna have to do one variable for each variable in the 
struct...

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[Lamex via Digitalmars-d]

On Monday, 10 July 2017 at 01:51:11 UTC, 12345swordy wrote:

On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy 
when it comes to manual memory management. The solutions that 
I find here involves very hackish solutions which is not idea 
for me.


Alex


No responses!?


dtors not being virtual is the root cause of this issue (note the 
ctors aren't either but that's a bit different due to how super() 
works). This cant be fixed easily. Maybe the most simple 
workaround would be an @assumenogc attribute.

[Issue 17630] New: DMD treats imports as public imports when selectively imported

[via Digitalmars-d-bugs]

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

  Issue ID: 17630
   Summary: DMD treats imports as public imports when selectively
imported
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

foo.d:

---
module foo;
import c;
//import c : NotErase; // <- breaks build of module `bar`
---


bar.d:

---
module bar;
unittest
{
import foo : Erase; // A non-selective import correctly errors
assert(Erase == 2);
}
---


c.d:

---
module c;
int Erase = 2;
int NotErase = 2;
---

--

Re: Why is phobos so wack?

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/09/2017 06:12 PM, Adam D. Ruppe wrote:

On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:
I suppose I'm biased, and PHP/Python have a fair following, but after 
a few years of PHP coding (part time as part of a larger project) I'm 
not sure I will ever make a full psychological recovery..


PHP actually is one of the languages that call this `trim`

But I've never had the kind of problems with D's names that I have with 
PHP's assorted weirdness.


It's nowhere remotely as bad as PHP (frankly, nothing else is), but D's 
growth over the years *has* left Phobos with a bit of a..."temporal 
inconsistancy" issue. Some things have been ironed out a bit (like how 
there was a module or two that used to use very unix CLI'ish naming 
conventions instead of D-ish namings), but there's still more to be 
done. And more will continue to be needed, with (ex.) allocators getting 
more and more finalized.

Re: proposed @noreturn attribute

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/09/2017 05:14 PM, H. S. Teoh via Digitalmars-d wrote:

On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:

It's no more of a hack than leaving assert(0) in release code.


I wouldn't argue that. I do argue it's a hack compared to the
principled solution of a bottom type. -- Andrei


I like out{ assert(0); } for pretty much the same reasons as Steven
lists. The biggest pro is that **the language already supports it*.
Contract syntax already is meant to signal intent, and assert(0) signals
"never gets here". You can't find a better solution than this. All the
other alternatives require adding even more baggage to an already
heavy language, or compiler voodoo to recognize a particular pattern of
defining a type.  I'd say out{assert(0);} is the principled solution --
expressing something the current language can already express, and it's
the other alternatives that are "exotic".



Prioritizing "path of least resistense" over "this is cleaner and more 
principled" is the hallmark of C++-style langauge design. Please, 
please, please, let's stay away from that path.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

Let's call the bottom type 'B' for the moment, for convenience.

If we think of it like a floating point NaN, then any type construction of B 
yields a B:


const(B) -> B
B* -> B
B[] -> B
X[B] -> B
B[X] -> B

Since B cannot have a value, any expression that forms a B can be replaced with 
an assert(0).


B foo(); // declaration
foo() -> foo(); assert(0);

cast(B)exp -> exp; assert(0);

B b; -> assert(0);

Given a tuple of types:

alias T = tuple(B,X);

is T equivalent to which of:

B   (1)
tuple(X)(2)
tuple(Y,X)  (3)
tuple(B,X)  (4)

? I'm leaning toward (4) as making the most sense.

struct S {
   T t;
}

should then yield an error, while:

struct S {
   T[1..1] t; // t is of type X
}

would not.

Re: Variadic Template Pattern

[Jonathan M Davis via Digitalmars-d]

On Sunday, July 9, 2017 9:21:03 PM MDT FoxyBrown via Digitalmars-d wrote:
> Hi, I have a proposal, wondering about your opinions.
>
> Suppose one has a template function foo that accepts a variable
> number of parameters:
>
> auto foo(T...)();
>
> Suppose we actually want to have some type of order and type info
> instead:
>
> auto foo(int, string)();
>
> but we need a "variable" number of them such as
>
> auto foo(int, string, int, string)();
>
> auto foo(int, string, int, string, int, string)();
>
> ad nausea.
>
> We could simplify it all by allowing for a sort of pattern on the
> ... for variadics:
>
> auto food((int,string)...)();
>
>
> and, this, of course, expands to what was described earlier.
>
>
> Now, this can be accomplished already with the single template
> method and foreach/static if testing the type, but that seems
> like it's excessively verbose.

A helper template could be written to use in a template constraint which
checked that that number of arguments was a power of however many arguments
you gave it and that they matched those types in that order. You'd probably
need another helper to create a struct or something that held the pattern,
since putting one AliasSeq in front of another would just merge them (e.g.
matchPattern!(int, string, Args) wouldn't work), but I'm sure that it could
be done, leaving you with something like

auto foo(Args...)()
if(matchPattern!(Pattern!(int, string), Args))
{
...
}

And yes, it's a bit more verbose than your suggestion, but it's a lot less
verbose and more reusable than manually checking with foreach and static
assertions - and it doesn't require a language change, just enough
template-foo to write the helper template.

- Jonathan M Davis

JavacTo - translate java source to D

[Patrick via Digitalmars-d-announce]

Hello,

I'm pleased to announce a new java prototype application that is 
designed to translate java source into D source. Or any other 
language that support package, class, interface, and enum 
constructs and provides a built in memory garbage collection. 
Supporting D with JavacTo was my first choice!


JavacTo available at:
https://sourceforge.net/projects/javacto/

Please see the "How To use JavacTo.pdf" part of the download 
package for more information.


This tool is designed to explore the challenges faced in 
translating from one language to another. For example what type 
of code is suitable for auto-translation and what code will 
required complete rewrite? What level of automation can be 
expected? What java packages should be translated and what 
packages can be skipped? Are helper classes a good approach in 
bridging java to other language specific features? These are just 
a few questions that I've been working on as I've been writing 
this tool.


I think JavacTo is a good starting point for people who are 
interested in this topic.


IMHO moving java opensource projects to D has the potential to be 
an incredible win for the D language/community.



Patrick

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 01:27 PM, 12345swordy wrote:

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy when it 
comes to manual memory management. The solutions that I find here 
involves very hackish solutions which is not idea for me.


Alex


Seems related to https://issues.dlang.org/show_bug.cgi?id=17297. -- Andrei

Re: Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[12345swordy via Digitalmars-d]

On Sunday, 9 July 2017 at 17:27:51 UTC, 12345swordy wrote:

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy 
when it comes to manual memory management. The solutions that I 
find here involves very hackish solutions which is not idea for 
me.


Alex


No responses!?

Re: Faster alternatives to std.xml

[Jonathan M Davis via Digitalmars-d-learn]

On Saturday, July 8, 2017 8:45:57 PM MDT Nordlöw via Digitalmars-d-learn 
wrote:
> What's the fastest XML-parser on code.dlang.org?
>
> Are there any benchmarks that show performance improvements
> compared to std.xml?

I'm not aware of any benchmarks for std.xml, but from what I know of it, it
would likely lose them all.

I've used

http://code.dlang.org/packages/std-experimental-xml

which was a GSoC project last year and was aimed at becoming the new
std.xml, but it hasn't been touched since November. It seems like the author
got too busy with school, and it fell completely by the wayside. So, I don't
know what's going to happen to it. It's worked reasonably well for my needs,
but it does have bugs, and it needs some work. I'd still rather use it than
std.xml though.

- Jonathan M Davis

Re: The Nullity Of strings and Its Meaning

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, July 9, 2017 1:51:44 PM MDT kdevel via Digitalmars-d-learn wrote:
> > You also shouldn't rely on it returning null for a null input,
> > even when it currently does that.
>
> I assumed that a non-null string is returned for a non-null input.

There are going to be functions that return null rather than an empty slice
of the original array. You really can't rely on getting an empty array
instead of a null one from a function unless the documentation tells you
that. For most purposes, there is no practical difference between a null
array and an empty array, so very little code is written which cares about
the difference. The only place where I would expect a function in a library
to distinguish is if its documentation says that it does (e.g. if returning
null means something specific or if it specifically says that the result is
a slice of the input).

In general, relying on whether a dynamic array is null or not outside of
code that you control or functions that are explicit about what they so with
null is risky business.

Sometimes, I wish that null were not treated as empty, and you were forced
to allocate a new array or somesuch rather than having null arrays just work
- then you could actually rely on stuff being null or not - but that would
also result in a lot more segfaults when people screwed up. The status quo
works surprisingly well overall. It just makes it dangerous to do much with
distinguishing null arrays from empty ones.

- Jonathan M Davis

Re: Automatic invariant generation

[Jonathan M Davis via Digitalmars-d]

On Sunday, July 9, 2017 4:00:33 AM MDT Walter Bright via Digitalmars-d 
wrote:
> On 7/9/2017 3:37 AM, Steven Schveighoffer wrote:
> > Wait, you have stated many many times, a segfault is good enough, it's
> > not worth the added cost to do null pointer exceptions (a position I'm
> > completely in agreement with).
>
> That's right.
>
> > Yet, here is an example of where we have effectively added a
> > null pointer exception. > At the very least, this should be eliminated
> > on Linux and just use the signal handling null pointer error mechanism!
>
> You're a few years late, as pretty much nobody agreed with me that the
> operating system handling of it was plenty.

What I don't understand about this is that it's not like we have these sort
of checks in general - just in this weirdly specific case. I could
understand that argument if we were doing null pointer checks in general,
but we're not, and you clearly haven't given in to the push for that.

In _C++_, I have literally only seen a null this pointer inside a member
function twice in my career (and the second time it happened, I had to
explain what was happening to my coworkers - some of them being quite
knowledgeable - because they didn't even think that it was possible to call
a function with a null pointer and not have it blow up at the call site). I
have never seen this problem in D. I would be _very_ surprised if you
couldn't just remove this check, and no one would complain because they hit
this problem and didn't get an assertion.

> > Note that there is a significant difference between this situation
> > (where you are *adding* an extra check), and the argument to add
> > messages to asserts (where you are *already* asserting).
>
> It's not really different. It's the desire for ever more messages. I've
> long advocated that a file/line is quite sufficient, but I seem to be in
> a tiny minority of 1. Now 2. :-)

For some assertions, having more than a file and line number is nice (e.g.
if you have messages for your pre-condition assertions, then you can make it
so that when it fails, the programmer doesn't even need to look at the
source code), but for many, many assertions, having a message doesn't do
much for you IMHO. You need to look at the code anyway, and if it's
asserting an internal thing rather than DbC, then it's usually really not
the sort of thing where a message is going to help particularly. In such
cases, the only real benefit that I see from having an error message that
does more than tell you where the assertion was and what the call stack was
is that if you have a message, and there are several assertions in the same
area of code, then when an assertion fails, you're less likely to mistake
one assertion for another if the source you're looking at doesn't exactly
match the build that the person reporting the issue was using (and that
mismatch isn't always obvious if you're not just building and running your
code locally).

So, to an extent at least, I agree with you, but a number of folks do seem
to think that messages that add no information are better than no messages
for some reason, and unfortunately, there's now a PR to outright require
messages for all assertions in Phbos:

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

- Jonathan M Davis

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky via Digitalmars-d]

On Sunday, 9 July 2017 at 22:02:51 UTC, Meta wrote:


There's a couple posts he's made here but a lot of it's spread 
out across various talks, articles (I think) as well as 
newsgroup posts. Here's what I found with a quick google:


https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandrescu_on_c_concepts/
https://www.reddit.com/r/programming/comments/4jlkhv/accu_2016_keynote_by_andrei_alexandrescu/d391585/

And there's a ton of info on the internet about the C++ 
concepts proposal.


Ah, I guess it is very similar after all, except it'd be based on 
top of and coexist with all of D's design by introspection stuff 
(rather than exist without it as with C++), thus avoiding a lot 
of the downsides and getting best of both worlds.

[Issue 17612] [REG2.063] Segmentation fault with bad object.d

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17612] [REG2.063] Segmentation fault with bad object.d

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/9e486c36fc76b7ccf45e3d9f19fa9115e7986d19
fix Issue 17612 - [REG2.063] Segmentation fault with bad object.d

https://github.com/dlang/dmd/commit/49c0625f305907aa4f9d81aff3370598aac2f5b7
Merge pull request #6975 from WalterBright/fix17612

fix Issue 17612 - [REG2.063] Segmentation fault with bad object.d
merged-on-behalf-of: Martin Nowak 

--

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 07:34 PM, Meta wrote:

On Sunday, 9 July 2017 at 22:28:50 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 03:12 PM, Walter Bright wrote:

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent - 
there is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But there 
are some issues. What do we do with:


 typeof(assert(0))* p;

? What does that mean?


That would be a pointer that may only be null - a consequence of the 
typeof(assert(0)) being uninstantiable.


Generally I'm not too worried about constructs like 
typeof(assert(0))[], typeof(assert(0))*, use in templates etc - we 
don't need to "design" these cases, their behavior flows from the 
properties of typeof(assert(0)) itself.


Similarly, I don't recall ever there being a problem with 
typeof(null)*, typeof(null)[], people complaining they passed 
typeof(null) to a template where it did bad things, etc.



Andrei


`typeof(null)` actually has one valid value and doesn't crash the 
program when when you try to create an instance of it. We should not 
treat this the same as `typeof(null)`.


Agreed (with the mention it's not in contradiction with the above). -- 
Andrei

Having a strange issue with std.net.curl.HTTP as a struct dependency

[NoBigDeal256 via Digitalmars-d-learn]

I'm currently learning D and started working on one of my first 
projects which is an API wrapper. I'm currently having an issue 
with my program getting a InvalidMemoryOperationError upon 
exiting the process on Windows 7. On my Debian VM I get a 
segmentation fault.


I have tried to minimize the code as much as I possibly can while 
still reproducing the error. Here is the code:


import std.net.curl;

struct ThingA {

HTTP http;

this(HTTP http) {
this.http = http;

arrayOfThingBs();
}

ThingB[] arrayOfThingBs() {
ThingB[] thingBs;

thingBs ~= ThingB(this);

return thingBs;
}

}

struct ThingB {

ThingA thingA;

this(ThingA thingA) {
this.thingA = thingA;
}

}

void main() {
auto http = HTTP();
auto thingA = ThingA(http);
}


If I comment out the HTTP dependency like:

struct ThingA {

//HTTP http;

this(HTTP http) {
//this.http = http;

arrayOfThingBs();
}

ThingB[] arrayOfThingBs() {
ThingB[] thingBs;

thingBs ~= ThingB(this);

return thingBs;
}

}

The error goes away. The error also goes away if 
ThingA.arrayOfThingBs returns a single instance of ThingB instead 
of an array of ThingB. Removing ThingBs dependency on ThingA also 
gets rid of the error. I'm new to low level languages in general 
so maybe I'm doing something wrong, but this seems like really 
strange behavior.

[Issue 17545] [REG2.072] __traits(getAttributes, name) evaluates name to value prematurely

[via Digitalmars-d-bugs]

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/2e6c7ac3af5ec52aff63a779e781cab1a802dfa5
fix Issue 17545 - [REG2.072] __traits(getAttributes, name) evaluates name to
value prematurely

https://github.com/dlang/dmd/commit/1227633d355b0a6ab8f65d82247fcf0d5012129e
Merge pull request #6949 from WalterBright/fix17545

fix Issue 17545 - [REG2.072] __traits(getAttributes, name) evaluates …
merged-on-behalf-of: Martin Nowak 

--

[Issue 17545] [REG2.072] __traits(getAttributes, name) evaluates name to value prematurely

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 22:28:50 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 03:12 PM, Walter Bright wrote:

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is 
precedent - there is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. 
But there are some issues. What do we do with:


 typeof(assert(0))* p;

? What does that mean?


That would be a pointer that may only be null - a consequence 
of the typeof(assert(0)) being uninstantiable.


Generally I'm not too worried about constructs like 
typeof(assert(0))[], typeof(assert(0))*, use in templates etc - 
we don't need to "design" these cases, their behavior flows 
from the properties of typeof(assert(0)) itself.


Similarly, I don't recall ever there being a problem with 
typeof(null)*, typeof(null)[], people complaining they passed 
typeof(null) to a template where it did bad things, etc.



Andrei


`typeof(null)` actually has one valid value and doesn't crash the 
program when when you try to create an instance of it. We should 
not treat this the same as `typeof(null)`.

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/8a67b112405213d95089426b8ecfc598ee14d3fb
Fix Issue 17548 - [REG2.072.0] Forward reference error with scope function
parameters

Prior to this commit, in StructDeclaration.semantic the only two ways the
condition (symtab && !scx && semanticRun < PASSsemanticdone) may be true are:
 - if determineFields() fails
 - if a first semantic() call on the same struct is ongoing

But in the second case, setting semanticRun to PASSsemanticdone is wrong,
because if the semantic() call defers itself, the deferred semantic() call will
return immediately, resulting in a "has forward references" error during
semantic2().

https://github.com/dlang/dmd/commit/b61d20fdbda633d7dfcf18f1b81649f25e32d0c4
Add testcase for issue 17548.

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

https://github.com/dlang/dmd/commit/2f6db2fb8bef57e55a45fc555128bd9d9fbf328e
Merge pull request #6937 from Syniurge/alt-fix17548

Alternative fix to issue 17548 - [REG2.072.0] Forward reference error with
scope function parameters
merged-on-behalf-of: Martin Nowak 

--

[Issue 17548] [REG2.072.0] Forward reference error with scope function parameters

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Phobos PR in need of review/merge

[Seb via Digitalmars-d]

On Saturday, 8 July 2017 at 06:05:54 UTC, Meta wrote:
I thought I'd let everyone know that there has been a whopping 
36 PRs merged in the past week (versus 17 opened). We're now 
sitting at 114 open Phobos PRs. Thanks to the reviewers/mergers 
who put in the effort to get that number down.


Btw _every_ helping hand in reviewing PRs is very welcome.
It's not very difficult and usually just a "I reviewed this PR 
and it LGTM" helps to bump the priority.
Otherwise of course, the author should be notified about existing 
blocking points in his PR.


Since a couple of months, GitHub allows to list all PRs that 
haven't received a review (yet):


https://github.com/dlang/phobos/pulls?page=3=is%3Apr+is%3Aopen+review%3Anone

Also, you can filter out labelled PRs, e.g. all PRs except those 
that depend on work from the submitter:


https://github.com/dlang/phobos/pulls?utf8=%E2%9C%93=is%3Apr%20review%3Anone%20is%3Aopen%20-label%3A%22needs%20work%22%20

The "needs work" label gets automatically removed on a new push.

Re: iterate over variadic

[Lamex via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 22:21:59 UTC, FoxyBrown wrote:
How can we iterate over a variadic and have it's index. I'll do 
different things depend on if it's an even or odd index, but 
seems to be no way to get it.



import std.stdio;
import std.typecons, std.meta;

template indexedAllSatisfy(alias F, T...)
{
bool doTest()
{
bool result = true;
import std.range: iota;
foreach(i; aliasSeqOf!(iota(0, T.length)))
result &= F!(T[i], i, T.length);
return result;
}
enum indexedAllSatisfy = doTest();
}

unittest
{
template evenIntString(T, int index, int length)
{
static if (length & 1)
enum evenIntString = false;
else static if (index & 1)
enum evenIntString = is(T == string);
else
enum evenIntString = is(T == int);
}

static assert(indexedAllSatisfy!(evenIntString, int, string, 
int, string));
static assert(!indexedAllSatisfy!(evenIntString, int , 
string, char, Object));

}

Re: iterate over variadic

[drug via Digitalmars-d-learn]

10.07.2017 01:21, FoxyBrown пишет:
How can we iterate over a variadic and have it's index. I'll do 
different things depend on if it's an even or odd index, but seems to be 
no way to get it.




auto foo(Types...)()
{
foreach(T; Types)
{
// do what you need
}
}
index could be added like usual

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 06:32 PM, Andrei Alexandrescu wrote:

On 07/09/2017 03:30 PM, Meta wrote:

alias Bottom = typeof(assert(0)); //for convenience


Speaking of which, I think we shouldn't give it a name, same as 
typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it 
is immediately clear it has a special status requiring a second look 
(which it does). -- Andrei


And btw this is technically a breaking change because somebody somewhere 
is liable to write code like:


void fun()
{
   ...
   return assert(0);
}

I'm not too worried about it though, and in fact we may even still 
accept it because hey typeof(assert(0)) converts to anything so how 
about it even converts to void.



Andrei

Re: Lazy range, extract only Nth element, set range size constraint?

[ag0aep6g via Digitalmars-d-learn]

On 07/09/2017 11:51 PM, biocyberman wrote:

Following is the code for a more generalized Fibonacci range.

Questions:

1. How do I get only the value of the Nth (i.e. N = 25) element in an 
idiomatic way?


As you've only got an input range, you have to popFront the 24 values 
that come before. You can use std.range.drop:



import std.range : drop;
auto twentyfifth = fib.drop(24).front;


But if you're not sure that the range actually has 25 elements, you 
should check `empty`, of course:



import std.range : popFrontN;
fib.popFrontN(24); /* or fib = fib.drop(24); */
if (!fib.empty)
{
auto twentyfifth = fib.front;
}


2. Can I set constraints in the range so that user gets warning if he 
asks for Nth element greater than a limit, say N> 30;


You can keep track of N in FibonacciRange and when it hits 30 you throw 
an exception or print a message or just set `empty` to true.


You can't make it a compilation warning/error as far as I can tell.

or if the actually 
range value at N is greater than datatype limit (e.g. max long)?


You can use std.experimental.checkedint to detect it at run time:


private bool _empty = false;
bool empty() const @property { return _empty; }

void popFront()
{
import std.experimental.checkedint : checked, Throw;
long tmp = 0;
try tmp = (checked!Throw(first)*multifactor + second).get;
catch (Throw.CheckFailure e) _empty = true;
first = second;
second = tmp;
}


(There may be a smarter way than making the operation throw an exception 
and catching that.)

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 03:30 PM, Meta wrote:

alias Bottom = typeof(assert(0)); //for convenience


Speaking of which, I think we shouldn't give it a name, same as 
typeof(null). Just keep it typeof(assert(0)). Then wherever it occurs it 
is immediately clear it has a special status requiring a second look 
(which it does). -- Andrei

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/b9e92f385a3399f170a010813b0b05aee1110731
fix Issue 17492 - [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion
failure

https://github.com/dlang/dmd/commit/ed24195a9ff2759b1c1ac2f0486e358eea8b56bc
Merge pull request #6964 from WalterBright/fix17492

fix Issue 17492 - [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): …
merged-on-behalf-of: Martin Nowak 

--

[Issue 17492] [REG 2.066] [ICE] AssertError@ddmd/dclass.d(1007): Assertion failure

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 03:12 PM, Walter Bright wrote:

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent - there 
is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But there 
are some issues. What do we do with:


 typeof(assert(0))* p;

? What does that mean?


That would be a pointer that may only be null - a consequence of the 
typeof(assert(0)) being uninstantiable.


Generally I'm not too worried about constructs like typeof(assert(0))[], 
typeof(assert(0))*, use in templates etc - we don't need to "design" 
these cases, their behavior flows from the properties of 
typeof(assert(0)) itself.


Similarly, I don't recall ever there being a problem with typeof(null)*, 
typeof(null)[], people complaining they passed typeof(null) to a 
template where it did bad things, etc.



Andrei

[Issue 17481] [REG 2.069.0] synchronized: Access Violation with dmd -O on win32

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17481] [REG 2.069.0] synchronized: Access Violation with dmd -O on win32

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/d728c0f9ba8f762682eced7da06f8123ed4d7f71
fix Issue 17481 - [REG 2.069.0] synchronized: Access Violation with dmd -O on
win32

https://github.com/dlang/dmd/commit/5fa367d499fd688d02e53afc9c2ceef31fb67619
Merge pull request #6965 from WalterBright/fix17481

fix Issue 17481 - [REG 2.069.0] synchronized: Access Violation with d…
merged-on-behalf-of: Martin Nowak 

--

Re: Why is phobos so wack?

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 9 July 2017 at 17:13:11 UTC, Dukc wrote:
To answer the part "why" about them sucking, is that they are 
generic.


Eh, that's not really why... this is just a crappy 
implementation. We can do a lot better with the library and a lot 
better with the compiler without losing any of the genericness.


Were join() just a regular function taking two strings, or two 
interfaces which string would implement, the messages would be 
better.


Better yes, but still actually a bit crappy. I have one step of 
an improvement in the works: 
https://github.com/dlang/dmd/pull/6806


Consider something similar to that for the constraints too. It 
could highlight that you passed a string instead of a "range of 
ranges" and you'd have a pretty good idea at a glance, even with 
the generic templates.


About C++ from what I've heard, generic error messages there 
are not only much worse than others, they are much worse than 
even D template errors!


Indeed.

Re: Fiber based UI-Toolkit

[Christian Köstlin via Digitalmars-d-learn]

On 09.07.17 23:12, bauss wrote:
> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out
>> for dlang. The second question is, if it would make sense at all to
>> have such a thing?
>>
>> christian
> 
> It doesn't really make sense to have that, because most (if not all)
> operating systems only allow rendering from a single thread and I
> believe OSX (possibly macOS too.) only allows it from the main thread.
> Which means the only thing you can really operate on other threads are
> events, but you'll always have to do callbacks to your UI thread in
> order to render.
Thanks for answering! you are touching exactly my question:
Lets say, that all the event handling is done by fiber-aware code (means
all io gives the thread free, when it would block, and perhaps
a yield function for calculation heavy operations). It would then
I think reduce the "risk" of a ANR (Application not responding (from
android) or the famous beachball) without sacrificing the clarity of the
code.

e.g. you want to download something from a webpage and process the data,
if you click a button. you cannot do this in the buttons-onclick
callback (because this is usually a long running operation and the
callback is called from the main thread). with fibers, the main thread
could continue running (and update the screen) as soon as the io thread
is blocking or the process thread calls yield (which he should on a
regular basis). after the processing as soon as the fiber gets back the
control, the result can easily be integrated back into the ui, because
its already in the right thread.
compare this with the traditionally apporach of spawning a new thread,
passing over the arguments, processing it, passing back the result and
integrating this into the ui, it could perhaps be "simpler".

on the other hand, the process code would get a little bit messy because
of the manually inserted yields (as far as i know, the erlang vm for
example inserts such instructions automatically every n instructions).

what do you think?

iterate over variadic

[FoxyBrown via Digitalmars-d-learn]

How can we iterate over a variadic and have it's index. I'll do 
different things depend on if it's an even or odd index, but 
seems to be no way to get it.

Re: proposed @noreturn attribute

[bachmeier via Digitalmars-d]

On Sunday, 9 July 2017 at 11:26:27 UTC, Steven Schveighoffer 
wrote:


The one disadvantage, is that -release removes contracts. So in 
this particular case, the out contract should remain.


Doesn't the compiler know about an out contract even with 
-release? I don't understand why -release would prevent the 
relevant information from being passed to the compiler.

Re: Why is phobos so wack?

[Adam D. Ruppe via Digitalmars-d]

On Sunday, 9 July 2017 at 17:07:16 UTC, bitwise wrote:
I suppose I'm biased, and PHP/Python have a fair following, but 
after a few years of PHP coding (part time as part of a larger 
project) I'm not sure I will ever make a full psychological 
recovery..


PHP actually is one of the languages that call this `trim`

But I've never had the kind of problems with D's names that I 
have with PHP's assorted weirdness.

[Issue 17629] New: package.di files cannot be used

[via Digitalmars-d-bugs]

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

  Issue ID: 17629
   Summary: package.di files cannot be used
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

Unlike other .d files, package.d files cannot have interface-file counterparts.

if a/package.d exists, "import a" works.
if a/package.di exists, "import a" does not work.

If both exist, the latter is ignored.

--

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 21:59:04 UTC, Nick Sabalausky wrote:

On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:


I'm sorry if I misunderstood what you're proposing, but isn't 
this exactly what C++ set out to do with concepts? If that's 
the case, I'd recommend you look up some of Andrei's 
refutation of concepts in favour of template guards and 
`static if`.


Shit, I hope not :/ I gave up following C++ developments 15 
years ago. Happen to have a link handy to that refutation?


There's a couple posts he's made here but a lot of it's spread 
out across various talks, articles (I think) as well as newsgroup 
posts. Here's what I found with a quick google:


https://www.reddit.com/r/cpp/comments/4jqg5z/andrei_alexandrescu_on_c_concepts/
https://www.reddit.com/r/programming/comments/4jlkhv/accu_2016_keynote_by_andrei_alexandrescu/d391585/

And there's a ton of info on the internet about the C++ concepts 
proposal.

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky via Digitalmars-d]

On Sunday, 9 July 2017 at 20:42:39 UTC, Meta wrote:


I'm sorry if I misunderstood what you're proposing, but isn't 
this exactly what C++ set out to do with concepts? If that's 
the case, I'd recommend you look up some of Andrei's refutation 
of concepts in favour of template guards and `static if`.


Shit, I hope not :/ I gave up following C++ developments 15 years 
ago. Happen to have a link handy to that refutation?

Lazy range, extract only Nth element, set range size constraint?

[biocyberman via Digitalmars-d-learn]

Following is the code for a more generalized Fibonacci range.

Questions:

1. How do I get only the value of the Nth (i.e. N = 25) element 
in an idiomatic way?


2. Can I set constraints in the range so that user gets warning 
if he asks for Nth element greater than a limit, say N> 30; or if 
the actually range value at N is greater than datatype limit 
(e.g. max long)? Maybe this should be done outside of the range, 
i.e. do check before accessing the range?


#!/usr/bin/env rdmd
import std.stdio : writeln;
long multifactor = 4;
int elemth = 25;

struct FibonacciRange
{
  long first = 1;
  long second = 1;

  bool empty() const @property
  {
   // how to stop at n = 30?
return false;
  }

  void popFront()
  {
long tmp = 0;
tmp = first*multifactor + second;
first = second;
second = tmp;
  }

  long front() const @property
  {
return first;
  }
}

void main()
{
import std.range : take;
import std.array : array;

FibonacciRange fib;

auto fib10 = take(fib, elemth);
long[] the10Fibs = array(fib10);
}

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 21:32:31 UTC, Walter Bright wrote:

On 7/9/2017 1:24 PM, Meta wrote:

Another case that we should probably just statically disallow:

alias ImmutableBottom = immutable Bottom; //Ditto for shared, 
const, etc.


This obviously doesn't make any sense anyway.




Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?


I was thinking about that (and in fact, making Bottom a "viral" 
type in the same way that NaN is a viral value), but it's not 
really worth it and we might as well make it an error. It can't 
occur in any template code if we disallow passing Bottom as a 
template argument, e.g., the following would fail:


alias Pointificate(T) = T*;
alias Immutable(T) = immutable T;

//Error: cannot pass Bottom as a template type argument
alias PointerToBottom = Pointificate!Bottom;
alias ImmutableBottom = Immutable!Bottom;

So the only place left where we could make a modified Bottom type 
would be doing `alias Immutable Bottom = immutable Bottom` and 
the like. It doesn't really matter either way, I don't think, but 
we might as well keeps things streamlined and just disallow 
everything to do with Bottom that we don't like. Unless there's a 
compelling reason to be able to apply immutable, shared, etc. to 
Bottom (and I don't see how there can be as you can never have a 
value of type Bottom that could be immutable, shared, etc. 
anyway) we should just disallow it.


Some functional languages do allow you to create things like 
`Either!(T, Bottom)` (from the Reddit thread: "Sometimes you have 
a generic procedure over a sum type and you want to pass it a 
single thing: `Either a Bottom` is isomorphic to a.") but I don't 
see a reason for us to ever need to do that.

LDC 1.3.0

[kinke via Digitalmars-d-announce]

Hi everyone,

LDC 1.3.0, the LLVM-based D compiler, is available for download!
This release is based on the 2.073.2 frontend and standard 
library and supports LLVM 3.5-4.0.


Some of the new features since v1.2:

* Improved cross-compilation abilities
  * Generate static libs for all targets
  * Experimental integration of LLD, the LLVM cross-linker
(still limited to Windows/MSVC targets)
  * More LLVM targets enabled for the prebuilt packages
* Includes first experimental version of DCompute for OpenCL/CUDA 
targets

* Support for Visual Studio 2017
* Bundled with static and shared runtime libraries (Linux and OSX)
* Bundled with rdmd, ddemangle and dustmite in addition to dub

Full release log and downloads: 
https://github.com/ldc-developers/ldc/releases/tag/v1.3.0


Regards,
kinke

Re: Call for arms: Arch Linux D package maintenance

[bachmeier via Digitalmars-d-announce]

On Sunday, 9 July 2017 at 19:56:20 UTC, Seb wrote:


Ouch - so how do we improve the status quo?
It's July, the packages are still listed as orphans [1], 
haven't received the 2.074.1 update and the Arch TUs are 
clearly not interested in maintaining it (its flagged as 
out-of-date since beginning of June). Moreover, with the recent 
move to -fPIC (which currently is in -fPIC), the packages would 
need a rebuilt with -fPIC (see [2]).

Anyone with an idea?

[1] https://www.archlinux.org/packages/community/x86_64/dmd
[2] 
http://forum.dlang.org/post/gpbyhmdsudlmapsvv...@forum.dlang.org


As I wrote elsewhere in this thread, I quit using Arch because of 
related problems. The answer (assuming things are still run the 
way they were back then) is that you're not able to do anything 
about it. You won't see anything done with the official package 
and you won't be able to put anything in AUR because there is an 
official package. Perhaps we can post a pkgbuild on dlang.org.

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/9/2017 1:24 PM, Meta wrote:

Another case that we should probably just statically disallow:

alias ImmutableBottom = immutable Bottom; //Ditto for shared, const, etc.

This obviously doesn't make any sense anyway.




Wouldn't `immutable(Bottom)` simply resolve to `Bottom`?

[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 #12 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/druntime

https://github.com/dlang/druntime/commit/ce863ecdd9ba0e56a40c8afa7b247946702f2995
Fix issue 16856: Don't use dlopen from the fini sections

In case finalizers are called from the runtime linker
we shouldn't try to get handle to and reference the
dying shared object. This was used just for the asserting,
so this simply removes the assert making it working on the
platforms where this is strictly forbiden (e.g. FreeBSD 12).

https://github.com/dlang/druntime/commit/1d983500f8d66b2bcb8fac514b2b23394ab60b37
Merge pull request #1862 from Burgos/dso

Fis issue 16856: Don't use dlopen from the fini sections
merged-on-behalf-of: Sebastian Wilzbach 

--

Variadic Template Pattern

[FoxyBrown via Digitalmars-d]

Hi, I have a proposal, wondering about your opinions.

Suppose one has a template function foo that accepts a variable 
number of parameters:


auto foo(T...)();

Suppose we actually want to have some type of order and type info 
instead:


auto foo(int, string)();

but we need a "variable" number of them such as

auto foo(int, string, int, string)();

auto foo(int, string, int, string, int, string)();

ad nausea.

We could simplify it all by allowing for a sort of pattern on the 
... for variadics:


auto food((int,string)...)();


and, this, of course, expands to what was described earlier.


Now, this can be accomplished already with the single template 
method and foreach/static if testing the type, but that seems 
like it's excessively verbose.

Re: proposed @noreturn attribute

[H. S. Teoh via Digitalmars-d]

On Sun, Jul 09, 2017 at 02:01:08PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:
> > It's no more of a hack than leaving assert(0) in release code.
> 
> I wouldn't argue that. I do argue it's a hack compared to the
> principled solution of a bottom type. -- Andrei

I like out{ assert(0); } for pretty much the same reasons as Steven
lists. The biggest pro is that **the language already supports it*. 
Contract syntax already is meant to signal intent, and assert(0) signals
"never gets here". You can't find a better solution than this. All the
other alternatives require adding even more baggage to an already
heavy language, or compiler voodoo to recognize a particular pattern of
defining a type.  I'd say out{assert(0);} is the principled solution --
expressing something the current language can already express, and it's
the other alternatives that are "exotic".


T

-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

Re: Fiber based UI-Toolkit

[Meta via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 21:12:24 UTC, bauss wrote:

On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
I wonder if there is any fiber based / fiber compatible 
UI-Toolkit out for dlang. The second question is, if it would 
make sense at all to have such a thing?


christian


It doesn't really make sense to have that, because most (if not 
all) operating systems only allow rendering from a single 
thread and I believe OSX (possibly macOS too.) only allows it 
from the main thread. Which means the only thing you can really 
operate on other threads are events, but you'll always have to 
do callbacks to your UI thread in order to render.


Aren't all fibers executed from a single thread?

Re: Fiber based UI-Toolkit

[bauss via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
I wonder if there is any fiber based / fiber compatible 
UI-Toolkit out for dlang. The second question is, if it would 
make sense at all to have such a thing?


christian


It doesn't really make sense to have that, because most (if not 
all) operating systems only allow rendering from a single thread 
and I believe OSX (possibly macOS too.) only allows it from the 
main thread. Which means the only thing you can really operate on 
other threads are events, but you'll always have to do callbacks 
to your UI thread in order to render.

[Issue 17375] colliding modules detected with binutils 2.28 linker and shared libraries

[via Digitalmars-d-bugs]

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

--- Comment #9 from Seb  ---
> It should be made default on Arch anyhow after we've switched with 2.072.2

Sadly it's not the default on Arch yet, see e.g.

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

and my proposal to make it default for all Posix distros:

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

--

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/9/2017 12:30 PM, Meta wrote:

[...]


Some great info and links. It's a compelling argument to add a bottom type.

[Issue 17628] New: formattedWrite is impure on double

[via Digitalmars-d-bugs]

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

  Issue ID: 17628
   Summary: formattedWrite is impure on double
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: qs.il.paperi...@gmail.com

pure void main()
{
import std.format : formattedWrite;
auto app = appender!string;
app.formattedWrite!"%s"(1.0);
}

fails. formattedWrite can purely do its job for int and string. It should also
do for floating point types.

--

Re: Types: The Next Generation (Was: Why is phobos so wack?)

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 20:22:16 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
> On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
>> return str.join(" ");
>> [...]
>> Error: template std.array.join cannot deduce function from
argument
>> types !()(string, string)
>> [...]
>> simply trying to join a string[] with a separator.
>
> The error message sucks, but you clearly have a string when
you meant
> string[].

Related to this, I've been giving some thought lately to a 
little bit of re-designing types themselves. Specifically, type 
creation tools that go beyond what structs and classes give us 
and allow better handling D-style generics.


It's all very incomplete right now, but basically here's the 
gist:


Awesome as D's generics, ranges, etc all are, they do make two 
things far more convoluted than when using basic 
straightforward types: Function declarations, and error 
messages when things don't match.


So, why not encapsulate much of that stuff we merely *describe* 
in signatures for generic functions into genuine 
honest-to-goodness types?


There would be user-defined symbols, such as "InputRange" or 
"SomeString", or "RandomAccessRange!SomeString", which the type 
system sees as actual types. And naturally there would be some 
mechanism for actually defining those types. Then, defining a 
function like this:


SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}

...would automatically imply to the compiler all (or at least a 
lot of) the pluming we usually clutter the function declaration 
with: Defining the templated types and calling the appropriate 
if(isBlahBlah) constraints. About the only things remaining 
would be additional constraints not already defined by the 
next-gen types, and restrictions on how the parameters relate 
to each other.


Even better, having all that encapsulated into genuine types 
should make it easier for the compiler to provide better error 
messages.


I'm sorry if I misunderstood what you're proposing, but isn't 
this exactly what C++ set out to do with concepts? If that's the 
case, I'd recommend you look up some of Andrei's refutation of 
concepts in favour of template guards and `static if`.

Re: proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:

It's no more of a hack than leaving assert(0) in release code.


I wouldn't argue that. I do argue it's a hack compared to the 
principled solution of a bottom type.


I would argue a type hack in the compiler doesn't compare to the 
principaled use of existing syntax and semantics  ;)


-Steve

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 19:30:25 UTC, Meta wrote:
I thought some more about the ramifications of having a Bottom 
type in D. Having a special type like this interacts badly with 
most aspects of D's generic programming capabilities, even on 
the simplest level. At the least we would probably have to 
create special cases everywhere in the compiler and/or 
libraries that check if the type we're working with is the 
bottom type. A few simple cases I can think of off the top of 
my head:


alias Bottom = typeof(assert(0)); //for convenience

Bottom*  pb; //Must be statically disallowed as this makes no 
sense

Bottom[] ab; //ditto
cast(Bottom)1; //ditto


Another case that we should probably just statically disallow:

alias ImmutableBottom = immutable Bottom; //Ditto for shared, 
const, etc.


This obviously doesn't make any sense anyway.

Types: The Next Generation (Was: Why is phobos so wack?)

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/09/2017 09:26 AM, Adam D. Ruppe wrote:
> On Sunday, 9 July 2017 at 12:56:55 UTC, FoxyBrown wrote:
>> return str.join(" ");
>> [...]
>> Error: template std.array.join cannot deduce function from argument
>> types !()(string, string)
>> [...]
>> simply trying to join a string[] with a separator.
>
> The error message sucks, but you clearly have a string when you meant
> string[].

Related to this, I've been giving some thought lately to a little bit of 
re-designing types themselves. Specifically, type creation tools that go 
beyond what structs and classes give us and allow better handling 
D-style generics.


It's all very incomplete right now, but basically here's the gist:

Awesome as D's generics, ranges, etc all are, they do make two things 
far more convoluted than when using basic straightforward types: 
Function declarations, and error messages when things don't match.


So, why not encapsulate much of that stuff we merely *describe* in 
signatures for generic functions into genuine honest-to-goodness types?


There would be user-defined symbols, such as "InputRange" or 
"SomeString", or "RandomAccessRange!SomeString", which the type system 
sees as actual types. And naturally there would be some mechanism for 
actually defining those types. Then, defining a function like this:


SomeString fizzbar(RandomAccessRange!SomeNumeric r) {...}

...would automatically imply to the compiler all (or at least a lot of) 
the pluming we usually clutter the function declaration with: Defining 
the templated types and calling the appropriate if(isBlahBlah) 
constraints. About the only things remaining would be additional 
constraints not already defined by the next-gen types, and restrictions 
on how the parameters relate to each other.


Even better, having all that encapsulated into genuine types should make 
it easier for the compiler to provide better error messages.


Thought could also be put into additional type-creation tools that cater 
specifically to common things (again, such as ranges) to help streamline 
the process of creating them (ranges are awesome, but let's face it, 
defining them can be a bother - there's gotta be some way to make it 
simpler. For example, input ranges especially would GREATLY benefit from 
being definable in the mannar of C# stackless coroutines).


And of course, Nemerle-like (ML/Haskell-inspired) algebraics would be a 
wonderful capability to encorporate as well.


Another area to explore would be merging the two sets of parameter lists 
(the compile-time list and the run-time list) into one list. Certain 
types would be known to imply "compile-time". A keyword/attr could be 
used to force compile-time or runtime. And for other params, a 
sufficiently-smart compiler could conceivably even choose "runtime" vs 
"compile-time" (or even, "it varies") based on optimization priorities. 
It would simplify the syntax for users, and help get around fear of 
templates.


Obviously this is all very incomplete, but it's an idea I think is 
rather interesting.

Re: Call for arms: Arch Linux D package maintenance

[Seb via Digitalmars-d-announce]

On Monday, 17 April 2017 at 11:04:11 UTC, R McGuire wrote:

On Thursday, 13 April 2017 at 09:34:00 UTC, Atila Neves wrote:

On Tuesday, 11 April 2017 at 16:17:32 UTC, John Colvin wrote:
On Thursday, 16 February 2017 at 19:58:47 UTC, Rory McGuire 
wrote:

[...]


Any news on this? The arch packages are listed as orphaned.


Same question, and adding that I volunteer to take over.

Atila


Are you involved in Arch?

The update is that Arch TUs are not likely to accept one of us 
that is not very involved in Arch. I've been watching the Arch 
mailing lists a bit and two users that tried to get involved 
were rejected and one user who is _very_ involved and has been 
for years got accepted.


I have tried to contact the last person that built the packages 
to see I could help with the dlang packages but have not 
received a reply yet.



Ouch - so how do we improve the status quo?
It's July, the packages are still listed as orphans [1], haven't 
received the 2.074.1 update and the Arch TUs are clearly not 
interested in maintaining it (its flagged as out-of-date since 
beginning of June). Moreover, with the recent move to -fPIC 
(which currently is in -fPIC), the packages would need a rebuilt 
with -fPIC (see [2]).

Anyone with an idea?

[1] https://www.archlinux.org/packages/community/x86_64/dmd
[2] 
http://forum.dlang.org/post/gpbyhmdsudlmapsvv...@forum.dlang.org

Re: dmd and Archlinux

[Seb via Digitalmars-d]

On Sunday, 9 July 2017 at 19:33:45 UTC, Antonio Corbi wrote:

On Sunday, 9 July 2017 at 19:21:48 UTC, Seb wrote:

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

[...]



I think the Arch Linux TUs are in the process of enabling 
-fPIC by default, see e.g. [1] - it might be releated to this?
In any case - building dmd/druntime/phobos with -fPIC enabled 
is a good idea and since 2.072.2 the official releases do so. 
Not sure why it's not done on Arch, maybe because Dicebot 
stepped down as maintainer? (see [2, 3]).


[1] 
https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028918.html

[2] http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com
[3] http://forum.dlang.org/post/o6sldo$1pad$1...@digitalmars.com


Hi Seb!

I think you are right. Official releases (the ones downloaded 
from dlang.org via curl) work for me.


A. Corbi



Maybe phobos/5586 [1] helps us. Of course the package would need 
to be rebuilt by the Arch Linux maintainers. Something I am not 
sure whether they are interested - the packages are orphaned and 
flagged out-of-date since more than a month [2]. Maybe you have 
an idea?


[1] https://github.com/dlang/phobos/pull/5586
[2] 
http://forum.dlang.org/post/ppyeysvwmgjpchazu...@forum.dlang.org

Re: proposed @noreturn attribute

[Stefan Koch via Digitalmars-d]

On Sunday, 9 July 2017 at 19:12:45 UTC, Walter Bright wrote:

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent 
- there is no name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But 
there are some issues. What do we do with:


typeof(assert(0))* p;

? What does that mean?


Not valid.
Cannot take a pointer of typeof(assert(0)).

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

[Rainer Schuetze via Digitalmars-d]

On 09.07.2017 05:31, Nicholas Wilson wrote:
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?


There is a pull request by Walter to generate the type info on demand: 
https://github.com/dlang/dmd/pull/6561


Unfortunately it seems to need a bit more work.

Fiber based UI-Toolkit

[Christian Köstlin via Digitalmars-d-learn]

I wonder if there is any fiber based / fiber compatible UI-Toolkit out
for dlang. The second question is, if it would make sense at all to have
such a thing?

christian

Re: dmd and Archlinux

[Antonio Corbi via Digitalmars-d]

On Sunday, 9 July 2017 at 19:21:48 UTC, Seb wrote:

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

[...]



I think the Arch Linux TUs are in the process of enabling -fPIC 
by default, see e.g. [1] - it might be releated to this?
In any case - building dmd/druntime/phobos with -fPIC enabled 
is a good idea and since 2.072.2 the official releases do so. 
Not sure why it's not done on Arch, maybe because Dicebot 
stepped down as maintainer? (see [2, 3]).


[1] 
https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028918.html

[2] http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com
[3] http://forum.dlang.org/post/o6sldo$1pad$1...@digitalmars.com


Hi Seb!

I think you are right. Official releases (the ones downloaded 
from dlang.org via curl) work for me.


A. Corbi

Re: proposed @noreturn attribute

[Meta via Digitalmars-d]

On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:

It's no more of a hack than leaving assert(0) in release code.


I wouldn't argue that. I do argue it's a hack compared to the 
principled solution of a bottom type. -- Andrei


I thought some more about the ramifications of having a Bottom 
type in D. Having a special type like this interacts badly with 
most aspects of D's generic programming capabilities, even on the 
simplest level. At the least we would probably have to create 
special cases everywhere in the compiler and/or libraries that 
check if the type we're working with is the bottom type. A few 
simple cases I can think of off the top of my head:


alias Bottom = typeof(assert(0)); //for convenience

Bottom*  pb; //Must be statically disallowed as this makes no 
sense

Bottom[] ab; //ditto
cast(Bottom)1; //ditto

struct TupleLike(T...)
{
T fields;
}

//What now? Do we allow this type to be instantiated but never 
created,
//as it contains Bottom? Or do we allow it to be instantiated and 
created,
//but the program crashes at runtime when it actually attempts to 
create a

//value of type Bottom?
TupleLike!(string, int, Bottom) t;

//Likewise. Either user code will have to add `if (!is(T == 
Bottom))`

//every time they define a wrapper struct like this, or an error
//would be generated from inside the aggregate the declares a `T 
t`

//member. The former is tedious, the latter defeats the purpose
//of template guards in the first place
alias Bad = Nullable!Bottom;

And I'm sure there are many more.

We could make passing Bottom as a template argument an error, 
which seems reasonable to me (this is the route Rust goes, I 
think). Here's a few good links:


https://doc.rust-lang.org/book/second-edition/ch19-04-advanced-types.html#the-never-type--that-never-returns
https://www.reddit.com/r/rust/comments/3j22vx/what_is_the_meaning_of_as_a_return_type/
https://github.com/rust-lang/rfcs/pull/1216

There's a discussion in that Reddit thread about some of the 
advantages/disadvantages of making Bottom a first-class type.


Also a point of interest is that by adding a Bottom type to D and 
with a bit of fiddling we can *almost* implement `assert(0)` in 
library code as opposed to in the compiler:


void assert(T)(lazy T cond, lazy string msg = "")
if (is(typeof(cast(bool)cond))
{
if (is(T == int) && cond == 0))
{
//Compiles recognizes that a value of type Bottom
//is being created and inserts a HLT instruction
//(Or whatever it is that assert(0) does nowadays)
Bottom impossible;
}

if (cond)
return;

if (msg.length)
{
import std.stdio;
stderr.writeln(msg);
}
assert(0);
}

I say almost because there's no way in user code to detect the 
specific form `assert(0)` without making changes to how we call 
it. A user could unintentionally halt the program by doing 
something like `assert(m - n, "m and n should not be the same")`. 
It could be done with templates but it'd break user code:


//`assert(0)` must now be called like `assert!0`
Bottom assert(int n: 0)(lazy string msg = "")
{
if (msg.length)
{
import std.stdio;
stderr.writeln(msg);
}
Bottom impossible;
}

Re: The Nullity Of strings and Its Meaning

[ag0aep6g via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 18:55:51 UTC, kdevel wrote:
Yes, it can obviously return one of the two representations of 
the empty D string.


The two being null and ""? There are more than those. One for 
every possible .ptr value.

Re: dmd and Archlinux

[Antonio Corbi via Digitalmars-d]

On Sunday, 9 July 2017 at 19:15:15 UTC, Nemanja Boric wrote:

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

[...]


Hm, I can't reproduce this issue with dmd 2.074.0-1. I've just 
installed dmd and it works out

of the box:

```
➜  arch tmp% pacman -Q | grep phob
libphobos-devel 1:2.074.0-1
➜  arch tmp% pacman -Q | grep dmd
dmd 1:2.074.0-1
➜  arch tmp% cat test.d
import std.stdio;

void main()
{
writeln("hello!");
}
➜  arch tmp% dmd -c test.d
➜  arch tmp% dmd test.o
➜  arch tmp% ./test
hello!
```


Thank's!

In my case the error persists.
I'm using the testing repo...so I think it must be related to 
that.


A. Corbi

Re: dmd and Archlinux

[Seb via Digitalmars-d]

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

Hi!

Are there any news about the status of packaging dmd for 
archlinux?


The last dmd compiler packaged is 2.074.0 and since the last 
batch of updated packages in archlinux, dmd generated objects 
fail to link with libphobos with erros like these:


/usr/bin/ld: /usr/lib/libphobos2.a(object_a_66e.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_b_58c.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_c_7f4.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_d_a07.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con ...


A. Corbi



I think the Arch Linux TUs are in the process of enabling -fPIC 
by default, see e.g. [1] - it might be releated to this?
In any case - building dmd/druntime/phobos with -fPIC enabled is 
a good idea and since 2.072.2 the official releases do so. Not 
sure why it's not done on Arch, maybe because Dicebot stepped 
down as maintainer? (see [2, 3]).


[1] 
https://lists.archlinux.org/pipermail/arch-dev-public/2017-July/028918.html

[2] http://forum.dlang.org/post/o6fbbu$1qli$1...@digitalmars.com
[3] http://forum.dlang.org/post/o6sldo$1pad$1...@digitalmars.com

Re: dmd and Archlinux

[Nemanja Boric via Digitalmars-d]

On Sunday, 9 July 2017 at 18:35:09 UTC, Antonio Corbi wrote:

Hi!

Are there any news about the status of packaging dmd for 
archlinux?


The last dmd compiler packaged is 2.074.0 and since the last 
batch of updated packages in archlinux, dmd generated objects 
fail to link with libphobos with erros like these:


/usr/bin/ld: /usr/lib/libphobos2.a(object_a_66e.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_b_58c.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_c_7f4.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_d_a07.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when 
making a shared object; recompile con ...


A. Corbi


Hm, I can't reproduce this issue with dmd 2.074.0-1. I've just 
installed dmd and it works out

of the box:

```
➜  arch tmp% pacman -Q | grep phob
libphobos-devel 1:2.074.0-1
➜  arch tmp% pacman -Q | grep dmd
dmd 1:2.074.0-1
➜  arch tmp% cat test.d
import std.stdio;

void main()
{
writeln("hello!");
}
➜  arch tmp% dmd -c test.d
➜  arch tmp% dmd test.o
➜  arch tmp% ./test
hello!
```

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:

We should use typeof(assert(0)) for Bottom.


That also leaves the door open for:

alias noreturn = typeof(assert(0));

Re: proposed @noreturn attribute

[Walter Bright via Digitalmars-d]

On 7/9/2017 6:13 AM, Andrei Alexandrescu wrote:
We should use typeof(assert(0)) for Bottom. There is precedent - there is no 
name for typeof(null).
I had forgotten about the typeof(null) thing. You're right. But there are some 
issues. What do we do with:


typeof(assert(0))* p;

? What does that mean?

Re: The Nullity Of strings and Its Meaning

[kdevel via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 15:10:56 UTC, ag0aep6g wrote:

On 07/09/2017 03:51 PM, kdevel wrote:

On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote:


[...]


A null char* is not a proper C string.


A C string is a sequence of storage units containing legitimate 
character values of which the last one is the NUL character.



It doesn't have length 0. It has no length.


In C a NULL ptr does not refer to anything including not to a C 
string.


A C function can't return a null char* when it's supposed to 
return an empty string.


That is true. And this it what mislead me thinking that D behaves 
the same.



But a D function can return a null char[] in that case.


Yes, it can obviously return one of the two representations of 
the empty D string.


Stefan

Re: proposed @noreturn attribute

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/09/2017 06:51 AM, Daniel N wrote:

On Sunday, 9 July 2017 at 10:31:47 UTC, Mr.D wrote:

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


Has anyone a better idea?


What about

scope(exit) assert(0);

?


void func()
out { assert(0); }
body
{
}


Too indirect and verbose. An attribute or special "return type" would 
just cut straight to the case.

Re: proposed @noreturn attribute

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/08/2017 08:17 AM, 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.


Pro:
- Having the indication "this doesn't return" syntactically be the 
return type makes a lot of sense. I like that a lot. (Though I'd have no 
objection to Walter's original suggestion either).


- It's one less built-in @attribute to scare people away with objections 
of "too many attributes"! (And admittedly, idiomatic D can end up with 
lots of attribtes all over the place.)


Con:
- Inferring that a type is meant to indicate "functions 'returning' this 
do not return", strikes me as very round-about, hackish, unintuitive and 
just unclean.


I really think this is one case where a dedicated compiler-understood 
symbol is not only fully justified but also much cleaner.


That would be my #1 top preference: Your suggestion here, but just make 
"NoReturn" (or whatever it'll be called) a special compiler-understood 
"type", not something inferred from the detailed of a library-provided type.


In any case, I'm definitely onboard with the idea of having SOME 
standard way to tell the compiler "this does not return". That would be 
nice to have.

dmd and Archlinux

[Antonio Corbi via Digitalmars-d]

Hi!

Are there any news about the status of packaging dmd for 
archlinux?


The last dmd compiler packaged is 2.074.0 and since the last 
batch of updated packages in archlinux, dmd generated objects 
fail to link with libphobos with erros like these:


/usr/bin/ld: /usr/lib/libphobos2.a(object_a_66e.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making 
a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_b_58c.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making 
a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_c_7f4.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making 
a shared object; recompile con -fPIC
/usr/bin/ld: /usr/lib/libphobos2.a(object_d_a07.o): relocation 
R_X86_64_32 against `.rodata.str1.1' can not be used when making 
a shared object; recompile con ...


A. Corbi

Re: proposed @noreturn attribute

[Nick Sabalausky (Abscissa) via Digitalmars-d]

On 07/08/2017 02:37 PM, Andrei Alexandrescu wrote:

nice touch of bottom (heh)


Where's D's PC-police now?

Re: proposed @noreturn attribute

[Stefan Koch via Digitalmars-d]

On Sunday, 9 July 2017 at 18:01:08 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:

It's no more of a hack than leaving assert(0) in release code.


I wouldn't argue that. I do argue it's a hack compared to the 
principled solution of a bottom type. -- Andrei


Adding a new builtin-type would also be okay.
But a compiler-recognized custom structs is quite costly and 
brings with it a much higher complexity and more importantly a 
higher compile-time cost.


It would also require yet another symbol in object.d which is too 
big as it is.

Re: NNTP error: Disconnected from server (Connection closed)

[Ali Çehreli via Digitalmars-d-learn]

On 07/09/2017 06:10 AM, kdevel wrote:

What's going on here?


Happens all the time. Last time (I think) Martin Nowak had said that a 
network packet trace would be helpful to debug this issue.


Ali

Re: proposed @noreturn attribute

[Andrei Alexandrescu via Digitalmars-d]

On 07/09/2017 12:19 PM, Steven Schveighoffer wrote:

It's no more of a hack than leaving assert(0) in release code.


I wouldn't argue that. I do argue it's a hack compared to the principled 
solution of a bottom type. -- Andrei

Re: CTFE output is kind of weired

[Andre Pany via Digitalmars-d-learn]

On Sunday, 9 July 2017 at 08:43:47 UTC, Andre Pany wrote:


Thanks for all the answers and explanations. I will create an 
issue to make the assert output more readable. The first 5 
times I didn't recognize the slice information at the end of 
the string and thought dmd isn't working at all anymore.


Kind regards
André


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

[Issue 17627] New: assert output in ctfe is irritating

[via Digitalmars-d-bugs]

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

  Issue ID: 17627
   Summary: assert output in ctfe is irritating
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

assert(false, strVar) has to be used to output a string variable in CTFE. At
the moment there is no other possibility as pragma(msg, ...) and writeln is not
working. 
Also with the new CTFE it isn't 100% clear whether ctfeWriteln will come:
http://forum.dlang.org/post/ynqedyhlpbolyfmhf...@forum.dlang.org

For this example 

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

The output is (dmd 2.075.0-b2):

C:\Users\user\Desktop>rdmd app
app.d(6): Error: "1234\x0a5678\x0a"[4..10]
app.d(17):called from here: test("1234\x0a5678\x0a")
Failed: ["dmd", "-v", "-o-", "app.d", "-I."]

Instead of the content of tmp, the full content is shown with the slice
information [4..10].
This output is in a real scenario quite irritating as the string is much longer
and a lot more logic is going on and also the string isn't passed back but a
structure. I already thought dmd isn't working at all, as the tmp variable
didn't changed its value. Only after having 5 looks at the minimal example
output, I saw the slice information.

--

Can't call destroy in nogc context, even though the class destructor being called is marked @nogc

[12345swordy via Digitalmars-d]

I have submitted a bug report regarding this:
https://issues.dlang.org/show_bug.cgi?id=17592

This is IMO severely limit the usage of emplace and destroy when 
it comes to manual memory management. The solutions that I find 
here involves very hackish solutions which is not idea for me.


Alex

[Issue 15750] net/isemail uses lots of redundant helper methods

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/5c31dd26ed289b397a4bad32ac29af6e77247ef7
Issue 15750 - remove substr from std.net.isemail

https://github.com/dlang/phobos/commit/e9ff980095462ee88713bcea3cc9852de5081e5b
Merge pull request #5585 from wilzbach/remove-substr

Issue 15750 - remove substr from std.net.isemail
merged-on-behalf-of: Jack Stouffer 

--

[Issue 17526] Add a set method for AA

[via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--

Re: Why is phobos so wack?

[Dukc via Digitalmars-d]

On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:
The error message sucks, but you clearly have a string when you 
meant string[].


To answer the part "why" about them sucking, is that they are 
generic.


Were join() just a regular function taking two strings, or two 
interfaces which string would implement, the messages would be 
better. I my experience D compiler is excellent at error messages 
when you don't go generic. Of course, that does not help much 
because the standard library is templated, not object-oriented.


Generics, and metaprogramming in general, is extremely hard to 
implement so that the error messages are even close to as good as 
elsewhere. No matter the language. Or rather, it can be made to 
give good messages, C# is a piece of proof for that. But that's 
also a reson why C# templates are so wimpy and ungeneral compared 
to C++ and D.


About C++ from what I've heard, generic error messages there are 
not only much worse than others, they are much worse than even D 
template errors!

Re: Why is phobos so wack?

[bitwise via Digitalmars-d]

On Sunday, 9 July 2017 at 13:26:31 UTC, Adam D. Ruppe wrote:
strip is used by Python and Ruby too... of the languages i 
know, it is about half a half.


BTW if you are ever searching, try my website: 
http://dpldocs.info/trim


I find this part of D very annoying as well.

D looks like a C language, with a standard library written by a 
PHP/Python developer. It's a shame for a language with so much 
potential to fall victim to such bad taste =x


I suppose I'm biased, and PHP/Python have a fair following, but 
after a few years of PHP coding (part time as part of a larger 
project) I'm not sure I will ever make a full psychological 
recovery..

Re: proposed @noreturn attribute

[Steven Schveighoffer via Digitalmars-d]

On Sunday, 9 July 2017 at 14:43:20 UTC, Andrei Alexandrescu wrote:

On 07/09/2017 10:10 AM, Steven Schveighoffer wrote:

I haven't seen another solution other than out { assert(0); }


Your own comment takes it to the recycle bin:

The one disadvantage, is that -release removes contracts. So 
in this

particular case, the out contract should remain.


That's already a hack on top of a hack.


An out contract should apply even when contracts are removed. The 
compiler can treat it as not returning even if contracts are 
removed. But the compiler could in this case leave the contract 
in as a stop gap in case the function does return.


I fact it's fine if it doesn't. It will just be UB.

It's no more of a hack than leaving assert(0) in release code.

-Steve

Re: The Nullity Of strings and Its Meaning

[ag0aep6g via Digitalmars-d-learn]

On 07/09/2017 03:51 PM, kdevel wrote:

On Sunday, 9 July 2017 at 10:32:23 UTC, ag0aep6g wrote:

[...]
As mentioned in the subject my posting is about the state of affairs 
wrt. the (non-)nullity of strings. In C/C++ once a char * variable 
became non-NULL 'it' never loses this property. In D this is not the 
case: The non-null value ""

'becomes' null in

"".decodeComponent


Nullity of D strings is quite different from nullity of C strings. A 
null D string is a valid string with length 0. A null char* is not a 
proper C string. It doesn't have length 0. It has no length.


A C function can't return a null char* when it's supposed to return an 
empty string. But a D function can return a null char[] in that case.


[...]
Sure. But I am writing about the string value which comprises the 
(non-)nullity of the string. This is not preserved.


Just like other pointers are not preserved. In the .ptr field of a D 
array, a null pointer isn't special. Null arrays aren't special beyond 
having a unique name.


[...]
string is not a pointer but a type. To the user of string it is 
completely irrelevant, if the nullity of the string is implemented by 
referring to a pointer inside the implementation of string.


string is a type that involves a pointer. The type is not opaque. The 
user can access the pointer.


A null array is not some magic (invalid) value. It's just just the one 
that has a null .ptr and a zero .length.


I think that's widely known, but it might not actually be in the spec. 
At least, I can't find it. The page on arrays [1] just says that 
"`.init` returns `null`" and that "pointers are initialized to `null`, 
without saying what null means for arrays. On the `null` expression [2], 
the spec mentions a "null value" of arrays, but again doesn't say what 
that means.


You also shouldn't rely on it returning null for a null input, even 
when it currently does that.


I assumed that a non-null string is returned for a non-null input.


As far as I see, you had no reason to assume that. If the spec or some 
other document mislead you, it needs fixing.


[...]
Yes. But that second proposition what not the one chosen in the 
documentation. It was not chosen because it does not extend to the 
nontrivial case where one has more than zero elements. ;-)


Or the spec's just poorly written there, and wasn't meant the way you've 
interpreted it.



[1] https://dlang.org/spec/arrays.html
[2] https://dlang.org/spec/expression.html#null