Re: Checked vs unchecked exceptions

[Sebastien Alaiwan via Digitalmars-d]

On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
On Monday, 26 June 2017 at 16:52:22 UTC, Sebastien Alaiwan 
wrote:
Checked exceptions allow a lot more precision about what types 
of exceptions a function can throw.


I totally agree that this is a problem with D right now.
This wasn't my point! I don't think there's a problem with D not 
having CE.
I was just pointing out the difference between "nothrow" 
specifications and CE.

[Issue 17560] Enhancement: view and copy full code example for offline compile/play

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #1 from greensunn...@gmail.com ---
>  First, the examples on the site do not always work

They _always_ work. We test this in our CI (e.g.
https://github.com/dlang/phobos/blob/master/posix.mak#L596).

> I propose an additional button that shows the complete, compilable example 
> text.

This is already in the queue: https://github.com/dlang/dlang.org/pull/1669
Feel free to vote for the PR ;-)

--

Re: What are the unused but useful feature you know in D?

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 27 June 2017 at 02:19:56 UTC, Nicholas Wilson wrote:

I think I'll write a DIP for this after my honours thesis.



Initial draft 
https://github.com/thewilsonator/DIPs/blob/Attributes/DIPs/DIP_attributes.md


Don't expect much from me until 4th of July.

Re: Go 1.9

[jmh530 via Digitalmars-d]

On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:


I'll post here after updating and testing the embedr package.


Great. I'll give it a go again when it's ready.

Re: Go 1.9

[bachmeier via Digitalmars-d]

On Monday, 26 June 2017 at 12:20:02 UTC, jmh530 wrote:

[...]

I might make another effort on this after work if I have time.


I think this will be fairly easily handled within the embedr R 
package. I should be able to put R.lib inside the package. R 
knows where to find R.dll. The only thing that remains is to find 
the LDC installation. I don't know how to automate that, but the 
user could give the path as input.


I'll post here after updating and testing the embedr package.

Re: What are the unused but useful feature you know in D?

[Nicholas Wilson via Digitalmars-d]

On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on 
request

3) imagine more potential going forward


I dislike doubling the keywords by having a 'not' case for each.
I'd rather have a systematic way of adding/removing attributes 
and udas.


Something like:
@gc
@!gc  (previously @nogc, compiler could even rewrite @nogc into 
@!gc for transition)


---

Anyway, I think we could just have a compile time switch for 
defaults.
Since some projects want to have pure, @safe, immutable by 
default, but others want to have @system @nogc. And no one 
wants write attributes more than they have to.


For example, I kind of like the current defaults since I like 
flexibility/changeability/editability of code. Because that 
makes coding fun which in turn usually means better code, 
features and productivity. Strictness is just a kind of salt 
that can be sprinkled on code in few difficult or dangerous 
cases.


Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on a 
regular basis (at least that's my perception)). Just bite the 
bullet and use Rust if you want to be actually safe.


I'm not a huge fan of immutable/const system either as it's 
kind of difficult to use and low benefits. It often leads into 
backtracking and changing your code all over the place (small 
change becomes an avalanche), because you found out in the last 
leaf function of your subsystem, that your design can't 
actually be immutable (basically, you forgot or couldn't 
imagine that elusive corner case no. 99).
The good thing is that immutable/const is actually strict and 
checkable. No holes like in @safe.


So if this change would happen, I would probably start all of 
my d files with

impure:
@system:
(@nogc:) // depending on my needs, I actually haven't had big 
issues with the gc

(nothrow:)
...

Which reminds me that it would be nice to group attributes as 
well.

Something like this:
alias @apiStrict = @safe immutable pure

int foo() @apiStrict
{
  return 1;
}


Hmm I really like this.
If we could have an AttributeAliasSeq then we could solve all of 
the inversion problems by simply removing them from the list.
This would also allow us to define a default set of attributes 
(in say core.attribute) that every symbol (except templates?) get 
tagged by.
Then you could change the default set of attributes by a version 
switch.


Or we could have the default attribute set apply to the module 
(declaration?) and be user overridable and then any explicit 
attributes applied to symbols override the default module 
attributes.


I think I'll write a DIP for this after my honours thesis.

Re: dlang website design

[dlangPupil via Digitalmars-d]

On Thursday, 22 June 2017 at 19:19:20 UTC, Ecstatic Coder wrote:

class TOTO

...I think that trying to
make the website very appealing to inexperienced programmers as 
well could significantly broaden its user base.


Although I am admittedly an LOB kind of person who cares little 
for games or gamification, I do see the benefit of using "fun" 
use-case examples, like a tic-tac-toe game, or a soda machine 
simulation.  Such recognizable zero-overhead/zero-noise metaphors 
simplify the tasks of understanding a program and learning its 
language.


By contrast, being asked to decipher a mysterious and unintuitive 
program like the fatuous tutu example would leave me resenting 
the distraction and cognitive overhead.  Dammit Jim, I'm a 
programmer, not a damned word puzzle competitor!


But that's just me!

So... instead of showcasing just one or another program type on 
the website's landing page, why not provide a tabbed dialog or 
menu that lets users select the kind of program that most 
interests them, e.g., LOB, web, games, STEM, etc.  This would 
avoid alienating those readers who believe that effective 
technical and instructional communication require the 
maximization of signal-to-noise ratio ABOVE ALL ELSE.


Some other ideas for introductory illustrative examples for the 
website would be to include for each program:


1) A description of the program's function so readers know what 
to look for.

2) The expected output.
3) A walk-through, when needed.
4) The same program in other languages, with call-outs to 
identify the unique features and benefits of Dlang.

Re: Phobos PR in need of review/merge

[Meta via Digitalmars-d]

Another PR that somebody in IRC mentioned: 
https://github.com/dlang/phobos/pull/5004


This one hasn't had any response for awhile either.

Re: What are the unused but useful feature you know in D?

[Mike via Digitalmars-d]

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:


// next gen D
module version(3.0) foo.bar; // opt in here
void whatever() {} // now @safe by default


That's a really good idea.

Phobos PR in need of review/merge

[Meta via Digitalmars-d]

Recently, a pull request was closed out of frustration by the 
submitter: https://github.com/dlang/phobos/pull/5309


I have asked them to re-submit the PR[1] in question so we can 
try to get it through. It's a mostly trivial change that could do 
with some eyes, comments, and most importantly, somebody with 
merge privileges to actually merge it.


On this topic, I feel like we've been falling behind lately in 
responding to PRs promptly, communicating with submitters on what 
changes (if any) are needed to get the PR into merge shape, and 
actually getting stuff merged (this isn't anything new of 
course). I don't have the data to back me up yet, but I am going 
to try to gather what I can and make a post about it sometime 
within the next month. Any ideas or insights are welcome.


1. https://github.com/dlang/phobos/pull/5515

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 00:29:53 UTC, crimaniak wrote:

On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:


And the good *way* to achieve this result would be the 
following:
- When visiting `startFoo`, the compiler automatically 
aggregates all different exceptions it may throw and stores 
the resulting set
- If `startFoo` is going to be part of a (binary) library and 
its symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if 
startFoo is called in scope S, but all of the exceptions in 
its exception set are caught (i.e. can't break out of scope 
S), it is treated as nothrow in S.

- Enclose the call to `startFoo` in B in a nothrow scope.
 After preparing my message I read tail of the thread and see 
your vision very close to mine. 


I wouldn't call it a vision, since I personally don't need it.
It's just that I consider checked exceptions as an excuse for not 
improving a deficient compiler.




So listing exceptions that can be thrown is a good thing 
because it helps you write more reliable code.


It is a bad thing because you force a human to do a machine's 
job.
This is a bad necessity, but a necessary opportunity. Sometimes 
you need to be sure that the compiler's vision matches yours.


I would need a concrete example that's not either solved by the 
steps mentioned in my post, or using compile time introspection 
on a function's exception set (as shown in John's idiomatic 
proposal [1]).


[1] 
http://forum.dlang.org/post/lxejskhonjtiifvvg...@forum.dlang.org

Re: isImplictlyConvertible for Variadic Templates

[ag0aep6g via Digitalmars-d-learn]

On 06/27/2017 02:59 AM, rpeio wrote:

struct Foo(V)
{
 this(Vs...)(Vs values) if (eachIsImplictlyConvertible!(T, Vs))
 {
 // do stuff
 }
}

This can be accomplished off the top of my head by taking the code from 
std.traits for "isImplicitlyConvertible" and making the following change.



[...]


Implementing this means I have an ostensibly valid method of 
accomplishing what I desire. Though, I am curious whether there's a way 
to facilitate this that is currently available in phobos, without having 
to implement another traits function.



import std.meta: allSatisfy, ApplyRight;
import std.traits: isImplicitlyConvertible;

this(Vs...)(Vs values)
if (allSatisfy!(ApplyRight!(isImplicitlyConvertible, T), Vs))
{
// do stuff
}


Though, for implicit conversion of all arguments to some type T you can 
also use this variant of variadic functions:



this(T[] values ...)
{
// do stuff
}

Re: DIY checking exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 00:10:32 UTC, jag wrote:

On Monday, 26 June 2017 at 21:53:57 UTC, John Colvin wrote:


I wonder what could be done with something like this:

void foo(int a)
{
if (a > 0)
throw new BlahException("blah");
throw new BloopException("bloop");
}

unittest
{
// NEW FEATURE HERE
alias Exceptions = __traits(thrownTypes, foo);
static assert (staticIndexOf!(BlahException, Exceptions)
>= 0);
static assert (staticIndexOf!(BloopException, Exceptions)
>= 0);
}

I'm imagining one could use that to do quite a lot of what 
checked exceptions provide.


So the only way for a programmer to know what exceptions can be 
thrown by a method is by running the code? In Java this is 
known while you are writing the code, even before you compile 
the code. And the compiler verifies that you are handling or 
passing on all possible exceptions. This is important.


As I have pointed out, implementing such a feature for function 
exception sets would be *one* component; the others are mentioned 
here [1].


[1] 
http://forum.dlang.org/post/uovtkvpdagzagzhya...@forum.dlang.org

isImplictlyConvertible for Variadic Templates

[rpeio via Digitalmars-d-learn]

I was wondering whether there was a method built into phobos for 
expanding the "isImplictlyConvertible" template to work for 
variadic templates.


To explain what I mean by this, normally 
"isImplicitlyConvertible(To, From)" checks whether or not a type 
"From" may implicitly be converted to a type "To".


struct Foo(V)
{
this(V)(V value) if (isImplictlyConvertible!(V, T))
{
// do stuff
}
}

When "From" is variadic, I would like it for each type in "From" 
to be checked whether it may implicitly be converted to type "To".


struct Foo(V)
{
this(Vs...)(Vs values) if (eachIsImplictlyConvertible!(T, Vs))
{
// do stuff
}
}

This can be accomplished off the top of my head by taking the 
code from std.traits for "isImplicitlyConvertible" and making the 
following change.


template eachIsImplictlyConvertible(To, From...)
{
enum bool eachIsImplictlyConvertible = is(typeof({
void fun(ref From vs)
{
void gun(To) {}
foreach (v; vs) // +
{
gun(v);
}
}
}));
}

Implementing this means I have an ostensibly valid method of 
accomplishing what I desire. Though, I am curious whether there's 
a way to facilitate this that is currently available in phobos, 
without having to implement another traits function.


Thanks,
rpeio

Re: Allocation trace

[sarn via Digitalmars-d]

On Saturday, 24 June 2017 at 22:15:47 UTC, Andrei Alexandrescu 
wrote:
Hello, does anyone have traces of allocations from real 
applications? Looking for the sequence of calls to malloc, 
realloc, and free, e.g.:


0 malloc 128
1 malloc 8192
2 malloc 32
3 free 1
...


Thanks,

Andrei


On *nix systems, you can use ltrace to generate this pretty 
easily.

Re: Checked vs unchecked exceptions

[crimaniak via Digitalmars-d]

On Monday, 26 June 2017 at 19:31:53 UTC, Moritz Maxeiner wrote:


And the good *way* to achieve this result would be the 
following:
- When visiting `startFoo`, the compiler automatically 
aggregates all different exceptions it may throw and stores the 
resulting set
- If `startFoo` is going to be part of a (binary) library and 
its symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if startFoo 
is called in scope S, but all of the exceptions in its 
exception set are caught (i.e. can't break out of scope S), it 
is treated as nothrow in S.

- Enclose the call to `startFoo` in B in a nothrow scope.
 After preparing my message I read tail of the thread and see 
your vision very close to mine. 


So listing exceptions that can be thrown is a good thing 
because it helps you write more reliable code.


It is a bad thing because you force a human to do a machine's 
job.
This is a bad necessity, but a necessary opportunity. Sometimes 
you need to be sure that the compiler's vision matches yours.

Re: Checked vs unchecked exceptions

[crimaniak via Digitalmars-d]

On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:

I am disappointed that D doesn't have checked exceptions.


Warning, Google translate is used! (sorry)

I fully support mckoder with regard to exceptions. This is a 
great advantage of Java. I think, the problem with the 
introduction of verified exceptions in D is rather psychological, 
as the authors and the community mostly came from C++. Indeed, in 
C++, the checked exceptions failed, but I think this is more a 
failure of C++ than the ideas of checked exceptions. The Java 
experience has shown that this is a powerful tool that really 
helps to write reliable programs. Most of the arguments against 
exceptions are somewhat similar to the arguments of language 
lovers with a weak dynamic typing, by which listing argument 
types seems tedious. The relevant objection is that there is a 
problem with lambdas. I think everyone who started using the 
stream API in Java 8 was faced with this problem. But who said 
that you need to exactly repeat the approach of Java? When I 
encountered this problem, I tried to write an analog of this API, 
only with support for exceptions. As a result, the root of the 
problem was easily identified. In Java, each exception type 
thrown is an additional method parameter, similar to the input 
parameters, and there are no variadic templates for them. The 
correct implementation should have some TypeTuple for all the 
types thrown. And the possibility of calculating it. The 
following thoughts should be considered as speculative, I 
understand that these ideas will not be accepted.
Take for start the system adopted in Java. Now add 'throws auto'. 
This does not mean 'throws Exception'! This means that the 
compiler must determine what exceptions this method or function 
throws. Now add a default - all functions where there are no 
throws are treated like 'throws auto'. What does this give us? 
The old code without throws continues to work, since exceptions, 
except for intercepted ones, successfully pop up to main() and 
are caught by runtime. But as soon as the author began to denote 
throws or nothrows, he gets all the benefits of the Java 
exception system. In addition, if the lower layer has changed, 
the intermediate layers that delegate the exceptions above do not 
need to be rewritten, only the code that deals directly with the 
exception processing and declares it with throws or nothrows will 
be affected. (I think that you should not abuse this, libraries 
that are supplied as a separate product should still encapsulate 
the underlying exceptions in their own).


In addition, now the specification of 'throws A, B, C' lowered to 
'throws ExceptionTypeTyple! (A, B, C)'. What does it give? We 
easily write templates that work with functions with any number 
of types of throws exceptions, and this can be handled according 
to the same rules as the other template parameters of the method.

Re: DIY checking exceptions

[jag via Digitalmars-d]

On Monday, 26 June 2017 at 21:53:57 UTC, John Colvin wrote:


I wonder what could be done with something like this:

void foo(int a)
{
if (a > 0)
throw new BlahException("blah");
throw new BloopException("bloop");
}

unittest
{
// NEW FEATURE HERE
alias Exceptions = __traits(thrownTypes, foo);
static assert (staticIndexOf!(BlahException, Exceptions) >= 
0);

static assert (staticIndexOf!(BloopException, Exceptions)
>= 0);
}

I'm imagining one could use that to do quite a lot of what 
checked exceptions provide.


So the only way for a programmer to know what exceptions can be 
thrown by a method is by running the code? In Java this is known 
while you are writing the code, even before you compile the code. 
And the compiler verifies that you are handling or passing on all 
possible exceptions. This is important.

[Issue 17560] New: Enhancement: view and copy full code example for offline compile/play

[via Digitalmars-d-bugs]

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

  Issue ID: 17560
   Summary: Enhancement: view and copy full code example for
offline compile/play
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: criman...@gmail.com

Now we have code examples which can be edited and run online. But there are two
circumstances that make it difficult to use examples for beginners. First, the
examples on the site do not always work, and secondly, they are incomplete in
terms of imports. Therefore, a neophyte can not just save an example to a disc
and start playing with it.
I propose an additional button that shows the complete, compilable example
text.

--

[Issue 12866] Append to std.container.Array of fixed size arrays

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/7c217521979df28deb23517a90c7a3c9aba970b6
Fix Issue 12866 - concatenating to std.container.array of static arrays

https://github.com/dlang/phobos/commit/8f98afc9ae8fba931bbe52b5c7ed23f8bc8180c4
Merge pull request #5473 from dmarquant/bug12866

Issue 12866: Allows concatenating of std.container.array with static arrays as
T.
merged-on-behalf-of: Petar Kirov 

--

Re: What are the unused but useful feature you know in D?

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
Anyway, I think we could just have a compile time switch for 
defaults.


Imagine having n libraries with pairwise different required 
defaults used in your application. Say goodbye to combined 
compilation, hello n separate required compiler invocations.


Since some projects want to have pure, @safe, immutable by 
default, but others want to have @system @nogc. And no one 
wants write attributes more than they have to.


That's why most of what I do is in templates, so the compiler 
infers them for me, anyway.




Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on a 
regular basis (at least that's my perception)). Just bite the 
bullet and use Rust if you want to be actually safe.


Except Rust is in exactly the same boat as D, because the same 
issues that apply to `@trusted` apply to `unsafe`, as well.




Which reminds me that it would be nice to group attributes as 
well.

Something like this:
alias @apiStrict = @safe immutable pure

int foo() @apiStrict
{
  return 1;
}


That would be useful.

Re: DIY checking exceptions

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 21:53:57 UTC, John Colvin wrote:

On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:

I am disappointed that D doesn't have checked exceptions.


I wonder what could be done with something like this:

void foo(int a)
{
if (a > 0)
throw new BlahException("blah");
throw new BloopException("bloop");
}

unittest
{
// NEW FEATURE HERE
alias Exceptions = __traits(thrownTypes, foo);
}

I'm imagining one could use that to do quite a lot of what 
checked exceptions provide.


Yes, that would be a D idiomatic implementation of the function 
exception set I mentioned [1].


[1] 
http://forum.dlang.org/post/uovtkvpdagzagzhya...@forum.dlang.org

DIY checking exceptions

[John Colvin via Digitalmars-d]

On Sunday, 25 June 2017 at 17:38:14 UTC, mckoder wrote:

I am disappointed that D doesn't have checked exceptions.


I wonder what could be done with something like this:

void foo(int a)
{
if (a > 0)
throw new BlahException("blah");
throw new BloopException("bloop");
}

unittest
{
// NEW FEATURE HERE
alias Exceptions = __traits(thrownTypes, foo);
static assert (staticIndexOf!(BlahException, Exceptions) >= 
0);
static assert (staticIndexOf!(BloopException, Exceptions) >= 
0);

}

I'm imagining one could use that to do quite a lot of what 
checked exceptions provide.

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

[via Digitalmars-d-bugs]

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

--- Comment #3 from Rainer Schuetze  ---
Ok, I can reproduce it with Win64 if I remove the (bad) condition that
disallows   decreasing line numbers.

--

[Issue 17521] -betterC programs should not link in Phobos runtime library by default

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 17521] -betterC programs should not link in Phobos runtime library by default

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/85873d9978028a7978121b25a00f6eed66f4f647
-betterC programs should not link in Phobos by default

- fixes Issue 11881, and 17521

https://github.com/dlang/dmd/commit/5a03f923fce98e9db6b3b563308b510c21ac5116
Merge pull request #6918 from WalterBright/link-betterC

fix Issue 17521 - -betterC programs should not link in Phobos by default
merged-on-behalf-of: Martin Nowak 

--

[Issue 11881] -betterC switch suffers from bit rot

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 11881] -betterC switch suffers from bit rot

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/85873d9978028a7978121b25a00f6eed66f4f647
-betterC programs should not link in Phobos by default

- fixes Issue 11881, and 17521

--

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Timon Gehr via Digitalmars-d]

On 20.06.2017 13:57, Mike Parker wrote:

DIP 1009 is titled "Improve Contract Usability".

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1009.md

All review-related feedback on and discussion of the DIP should occur in 
this thread. The review period will end at 11:59 PM ET on July 3 (3:59 
AM GMT July 4), or when I make a post declaring it complete.


At the end of Round 1, if further review is deemed necessary, the DIP 
will be scheduled for another round. Otherwise, it will be queued for 
the formal review and evaluation by the language authors.


Thanks in advance to all who participate.

Destroy!



The DIP is missing the corresponding syntax for invariants:

class C{
private int x=1;
invariant(x>0, "x must stay positive");
}

Implementation:
https://github.com/dlang/dmd/compare/master...tgehr:contract-syntax

Re: Checked vs unchecked exceptions

[Guillaume Boucher via Digitalmars-d]

On Monday, 26 June 2017 at 18:42:24 UTC, Ola Fosheim Grøstad 
wrote:
On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher 
wrote:
Java uses A, Rust/Go use B.  C++ uses B to some extend (e.g. 
in std::experimental::filesystem).


The C++17 filesystem api provides two alternatives, the 
standard filesystem_error exception and an output-paramater for 
capturing os-specific error codes. I'm not quite sure why they 
provide both, but I guess performance and the ability to 
compile for  runtimes with exceptions turned off could explain 
it.


Quoting the C++ standard:

Filesystem library functions often provide two overloads, one 
that
throws an exception to report file system errors, and another 
that sets an error_code.


[Note: This supports two common use cases:

   - Uses where file system errors are truly exceptional
 and indicate a serious failure.
 Throwing an exception is an appropriate response.
   - Uses where file system errors are routine
 and do not necessarily represent failure.
 Returning an error code is the most appropriate response.
 This allows application specific error handling, including 
simply ignoring the error.


 -- end note]


I would say that the overload without exceptions is the 
"standard" one.


It is rather clear though that C++ std lib relies heavily on 
exceptions.


[Citation needed]

Re: Checked vs unchecked exceptions

[Guillaume Boucher via Digitalmars-d]

On Monday, 26 June 2017 at 17:50:47 UTC, Moritz Maxeiner wrote:
I have tried using such Monads in D, but in the end it always 
ended up being too verbose or too hard to read compared to 
using exceptions or even simple error codes (with 0 == no 
error).


I haven't tried that yet, tbh.  visit is nice, but can't always 
be used.  So I guess unless D introduces syntax for pattern 
matching, it will always be verbose.


In that case a reference to an error code would be the most 
viable design in D.

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 18:31:50 UTC, jag wrote:

On Monday, 26 June 2017 at 17:43:08 UTC, Moritz Maxeiner wrote:
Here's the point: with checked exceptions good programmers 
can write good code.


With checked exceptions any programmer is forced to
a) annotate every single function with the complete aggregate 
of the exceptions that may be thrown by itself or the 
functions it calls
b) violate checked exceptions and limit its callers by marking 
itself as throwing a parent exception




Here's an example C# pseudocode to illustrate the problem:


No need, you can assume the people discussing this are familiar 
with the issue, it's not new.




class A {
   public static void startFoo() {
  if (/* Foo is not installed */)
  throw new FooNotInstalled();
  // ...
   }
}

Programmer B calls the above code like this:

class B {
   try {
  A.startFoo();
   }
   catch (FooNotInstalled) {
  // Tell user to purchase Foo
   }
}

Later programmer A updates his code because there are newer 
versions of Foo and he needs the newest version:


class A {
   public static void startFoo() {
  if (/* Foo is not installed */)
  throw new FooNotInstalled();
  if (/* Foo version is too old */)
  throw new FooVersionTooOld();
  // ...
   }
}

Now the code written by Programmer B crashes even though it 
compiles file. That's bad.


Had this been Java, programmer would be would be alerted to the 
fact that he needs to decide what do do if the version of Foo 
is too old. This is good.


And the good *way* to achieve this result would be the following:
- When visiting `startFoo`, the compiler automatically aggregates 
all different exceptions it may throw and stores the resulting set
- If `startFoo` is going to be part of a (binary) library and its 
symbol is exported, also export its exception set
- Improve the compiler's nothrow analysis such that if startFoo 
is called in scope S, but all of the exceptions in its exception 
set are caught (i.e. can't break out of scope S), it is treated 
as nothrow in S.

- Enclose the call to `startFoo` in B in a nothrow scope.



So listing exceptions that can be thrown is a good thing 
because it helps you write more reliable code.


It is a bad thing because you force a human to do a machine's job.

[Issue 16992] fromISOString, fromISOExtString, and fromSimpleString do not have examples

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--

[Issue 15950] Wish: __compressed_import("file.ext");

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
(In reply to ponce from comment #0)
> I've considered using CTFE to ZIP imported resources, but was advised not
> to. It may be prohibitive and use a lot of memory. It's an option though,
> perhaps the reasonable one.

Instead of using CTFE, how about compressing them as part of your build, and
decompressing them at runtime?

Using CTFE might be more realistic with Stefan's upcoming new CTFE engine.

--

[Issue 17468] Internal assertion fails during CTFE

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/e7a0c6bfc97bb8d9634db8def7e9f9904ffb864f
fix Issue 17468 - Internal Assertion fails during CTFE

https://github.com/dlang/dmd/commit/06e77c0b46cbef744266fab3f5752241f07c6606
Merge pull request #6859 from UplinkCoder/fx_on_stable

--

[Issue 17296] EINTR awareness - posix system calls can be interrupted by posix signal

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from greensunn...@gmail.com ---
First PR pull: https://github.com/dlang/phobos/pull/5503

--

Re: What are the unused but useful feature you know in D?

[Random D user via Digitalmars-d]

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on request
3) imagine more potential going forward


I dislike doubling the keywords by having a 'not' case for each.
I'd rather have a systematic way of adding/removing attributes 
and udas.


Something like:
@gc
@!gc  (previously @nogc, compiler could even rewrite @nogc into 
@!gc for transition)


---

Anyway, I think we could just have a compile time switch for 
defaults.
Since some projects want to have pure, @safe, immutable by 
default, but others want to have @system @nogc. And no one wants 
write attributes more than they have to.


For example, I kind of like the current defaults since I like 
flexibility/changeability/editability of code. Because that makes 
coding fun which in turn usually means better code, features and 
productivity. Strictness is just a kind of salt that can be 
sprinkled on code in few difficult or dangerous cases.


Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on a 
regular basis (at least that's my perception)). Just bite the 
bullet and use Rust if you want to be actually safe.


I'm not a huge fan of immutable/const system either as it's kind 
of difficult to use and low benefits. It often leads into 
backtracking and changing your code all over the place (small 
change becomes an avalanche), because you found out in the last 
leaf function of your subsystem, that your design can't actually 
be immutable (basically, you forgot or couldn't imagine that 
elusive corner case no. 99).
The good thing is that immutable/const is actually strict and 
checkable. No holes like in @safe.


So if this change would happen, I would probably start all of my 
d files with

impure:
@system:
(@nogc:) // depending on my needs, I actually haven't had big 
issues with the gc

(nothrow:)
...

Which reminds me that it would be nice to group attributes as 
well.

Something like this:
alias @apiStrict = @safe immutable pure

int foo() @apiStrict
{
  return 1;
}

Re: Checked vs unchecked exceptions

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
Java uses A, Rust/Go use B.  C++ uses B to some extend (e.g. in 
std::experimental::filesystem).


The C++17 filesystem api provides two alternatives, the standard 
filesystem_error exception and an output-paramater for capturing 
os-specific error codes. I'm not quite sure why they provide 
both, but I guess performance and the ability to compile for  
runtimes with exceptions turned off could explain it.


It is rather clear though that C++ std lib relies heavily on 
exceptions.

Re: Checked vs unchecked exceptions

[jag via Digitalmars-d]

On Monday, 26 June 2017 at 17:43:08 UTC, Moritz Maxeiner wrote:
Here's the point: with checked exceptions good programmers can 
write good code.


With checked exceptions any programmer is forced to
a) annotate every single function with the complete aggregate 
of the exceptions that may be thrown by itself or the functions 
it calls
b) violate checked exceptions and limit its callers by marking 
itself as throwing a parent exception




Here's an example C# pseudocode to illustrate the problem:

Programmer A writes this C# code:

class A {
   public static void startFoo() {
  if (/* Foo is not installed */)
  throw new FooNotInstalled();
  // ...
   }
}

Programmer B calls the above code like this:

class B {
   try {
  A.startFoo();
   }
   catch (FooNotInstalled) {
  // Tell user to purchase Foo
   }
}

Later programmer A updates his code because there are newer 
versions of Foo and he needs the newest version:


class A {
   public static void startFoo() {
  if (/* Foo is not installed */)
  throw new FooNotInstalled();
  if (/* Foo version is too old */)
  throw new FooVersionTooOld();
  // ...
   }
}

Now the code written by Programmer B crashes even though it 
compiles file. That's bad.


Had this been Java, programmer would be would be alerted to the 
fact that he needs to decide what do do if the version of Foo is 
too old. This is good.


So listing exceptions that can be thrown is a good thing because 
it helps you write more reliable code. If you are lazy you can 
always defeat the system by declaring your method as throwing a 
parent (or the root) exception class, in which case it is no 
worse than C#.

Re: D Milestones

[Patrick Schluter via Digitalmars-d]

On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote:
On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke 
wrote:
I think it would be good for all which want to invest their 
time in learning D to know more about the history and probably 
the future of D.


D frontend written in d?


And mentioning that building the first D frontend version takes 
0m14s (on an 2GHz intel server) instead of 1m50s of the last 
version with the C++ frontend (and that it still takes 14 seconds 
to build because the backend is still in C++).

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Rainer Schuetze from comment #1)
> Works alright on Windows.

Linux x64 here.

> Anything special in mod.d or can it be omitted?

If fun is in the same file as main, the line number still changes between
versions, but it points at the line containing fun's signature. That's not so
bad - it's not useful but at least it's not misleading wrong, as when fun is in
a separate module.

--

[Issue 17559] [REG2.073.0] Wrong line number in stack trace

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
Works alright on Windows. Anything special in mod.d or can it be omitted?

--

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 17:44:15 UTC, Guillaume Boucher wrote:
It is very well possible to use option B in D.  The most 
convenient one is making functions nothrow and use 
Algebraic!(T, ErrorCode), or, for void functions, have a 
parameter "ref ErrorCode".
If all functions in Phobos would either follow that pattern or 
provide an alternative nothrow overload, I would consider that 
problem solved.


I have tried using such Monads in D, but in the end it always 
ended up being too verbose or too hard to read compared to using 
exceptions or even simple error codes (with 0 == no error).

Re: Zero-cost version-dependent function call at -O0.

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 25 June 2017 at 23:02:28 UTC, Adam D. Ruppe wrote:

On Sunday, 25 June 2017 at 22:53:07 UTC, Johan Engelen wrote:

I meant semantically no call.


In the existing language, I think version (or static if) at the 
usage and definition points both is as good as you're going to 
get.


At the usage _and_ at definition point, indeed, that's a very 
good idea.


- Johan

[Issue 11881] -betterC switch suffers from bit rot

[via Digitalmars-d-bugs]

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

Gary Willoughby  changed:

   What|Removed |Added

 CC|d...@nomad.so|

--

[Issue 8378] /entry:_function is implemented, but undocumented.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
I assume this bug report is for OPTLINK?

/ENTRY shows up in the /? switch list (as "EN[try]"), so I don't see a problem
here.

--

Re: Zero-cost version-dependent function call at -O0.

[Johan Engelen via Digitalmars-d-learn]

On Sunday, 25 June 2017 at 23:02:28 UTC, Adam D. Ruppe wrote:


That'd be kinda tricky because the arguments would still be 
liable to be evaluated...


Well..
I guess someone might argue that's a mis-feature of my 
preprocessor example:  "foo(i++)" may not do what you want.  (So 
the C code would have to do "(void)param" for all params, to 
ensure evaluation and avoid compiler warning? =))


So I think I got things to work with inline IR! ^_^

https://godbolt.org/g/HVGTbx
```
version(none) {
  void foo(int a, int b, int c) { /*...*/ };
} else {
  pragma(LDC_inline_ir) R __ir(string s, R, P...)(P);
  alias foo = __ir!(`ret i32 0`, int, int, int, int);
}

void bar()
{
   int a;
   foo(a++,2,3);
}
```

-Johan

Re: Checked vs unchecked exceptions

[Guillaume Boucher via Digitalmars-d]

On Monday, 26 June 2017 at 16:52:22 UTC, Sebastien Alaiwan wrote:
Checked exceptions allow a lot more precision about what types 
of exceptions a function can throw.


I totally agree that this is a problem with D right now.  If you 
want to catch all errors, how are you supposed to remember what 
std.file.readText throws?  Or std.file.mkdir?


There are two solutions to this problem that I know of:

A) Checked exceptions
B) Error codes that can't be implicitly ignored

Java uses A, Rust/Go use B.  C++ uses B to some extend (e.g. in 
std::experimental::filesystem).


In my opinion, option B better than A because checked exceptions 
are incredibly verbose.  However, both are better than nothing 
(which is the current state of D right now).


It is very well possible to use option B in D.  The most 
convenient one is making functions nothrow and use Algebraic!(T, 
ErrorCode), or, for void functions, have a parameter "ref 
ErrorCode".
If all functions in Phobos would either follow that pattern or 
provide an alternative nothrow overload, I would consider that 
problem solved.

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 15:40:19 UTC, mckoder wrote:
On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer 
wrote:


No, checked exceptions leads to this (maybe not for you, but 
for 90% of developers out there):


void foo()
{
   functionWithException();
}

compiler: foo throws, and you need to handle or declare the 
exceptions it throws


void foo()
{
   try {
 functionWithException();
   } catch(Exception e) {} // shut up compiler
}



Why wouldn't you instead write:

void foo() throws Exception // shut up compiler
{
   functionWithException();
}

That's easier, and no worse than C# even though you have 
defeated checked exceptions.


Because that's even worse.
The `try catch` as least takes responsibility for handling the 
error - even if it is just intentionally ignoring it.
Your version delegates the responsibility up the call chain 
(which is in and of itself fine), but it - as you even stated - 
prevents the caller from using checked exceptions, i.e. you're 
cheating the system.


Here's the point: with checked exceptions good programmers can 
write good code.


With checked exceptions any programmer is forced to
a) annotate every single function with the complete aggregate of 
the exceptions that may be thrown by itself or the functions it 
calls
b) violate checked exceptions and limit its callers by marking 
itself as throwing a parent exception


Or, more succinct: You must either manually write things down the 
compiler could find out in a fraction of the time via static 
analysis, or cheat the system; both cases are bad code.

[Issue 11881] -betterC switch suffers from bit rot

[via Digitalmars-d-bugs]

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

--- Comment #19 from Walter Bright  ---
(In reply to Martin Nowak from comment #18)
> Use `extern(C) int main` to avoid the _d_run_main dependency of the
> generated C main wrapper.

That's right. If you're writing C code, it's better to use the C main()!

Whether the compiler should complain about a D main() in a -betterC compile is
another matter. I'd prefer to defer such issues (and there are several) until
we gain some experience in the field with it.

--

[Issue 7841] Better error message for wrong template argument with ref

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
Error message now looks like:

test.d(3,8): Error: template test.foo cannot deduce function from argument
types !()(const(int[])), candidates are:
test.d(1,6):test.foo(T)(ref T[] a)

Hopefully that qualifies as an improvement!

--

Re: Checked vs unchecked exceptions

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 26 June 2017 at 16:35:51 UTC, jmh530 wrote:
Just curious: how are checked exceptions different from setting 
nothrow as the default? Like you would have to write:


void foo() @maythrow
{
   functionWithException();
}

So for instance, you could still use your "//shut up compiler" 
code with the nothrow default.


I think the basic argument was that if throws-anything is the 
default expectation then people won't feel like silencing thrown 
exceptions, but allow them to propagate freely. Of course, if the 
function is marked nothrow then they still will have to silence 
any exceptions before returning, so same issue.


But, I am pretty convinced that this has more to do with tooling 
than usability. If the tooling is not created with evolving 
exceptions spec in mind then it becomes tedious to update the 
throw specification for functions higher up in the call-chain.


Another issue is that a function that takes a lambda/function as 
parameters will have to cover any exception that the parameter 
lambdas/function can throw as well. Which actually might be a 
good thing, as it forces you to think more clearly about where 
exceptions originate from: what-if-the-foreign-lambda throws an 
exception?


But it does have implications for how you work.

[Issue 11881] -betterC switch suffers from bit rot

[via Digitalmars-d-bugs]

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

--- Comment #18 from Martin Nowak  ---
Use `extern(C) int main` to avoid the _d_run_main dependency of the generated C
main wrapper.

--

[Issue 17361] latest windows 10 insider preview and dmd no longer runs.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #6 from Vladimir Panteleev  ---
Good to know you got it to work. Closing, then.

--

Re: What are the unused but useful feature you know in D?

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:

On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:


Yes, please do!  If we can push this through, D could be in a 
much, much better place in a few years' time!


As long as you don't introduce immutable by default, resulting 
in datastructures being littered with `mutable`.


Addendum: I'm also not in favor of `nothrow` by default, because 
imho that contradicts D's error handling using exceptions by 
default.

Re: dlang website design

[jmh530 via Digitalmars-d]

On Monday, 26 June 2017 at 17:15:50 UTC, bachmeier wrote:

On Monday, 26 June 2017 at 16:14:32 UTC, Seb wrote:

They publish a high-level vision every six months (e.g. 
https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot 
out a short blog post about it in the future, so that it 
receives more publicity?


As I recall, the hope was for communication more often than 
every six months, and with more detail. Personally, I don't 
know if it would help. They're not involved with much outside 
of the language itself, and for the most part, the language is 
not D's problem.


My sense is that communication is moving in the right direction. 
Not everything needs to come from Walter and Andrei.


I agree that a blog post on the next Vision document would be 
reasonable.

Re: What are the unused but useful feature you know in D?

[Adam D. Ruppe via Digitalmars-d]

On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:
As long as you don't introduce immutable by default, resulting 
in datastructures being littered with `mutable`.


Yeah, I'm against immutable by default. Also, my nogc, safe, etc 
by default idea does NOT apply to main() or virtual methods.


I have explained why before and feel like we are hijacking this 
thread now though

Re: dlang website design

[bachmeier via Digitalmars-d]

On Monday, 26 June 2017 at 16:14:32 UTC, Seb wrote:

They publish a high-level vision every six months (e.g. 
https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot 
out a short blog post about it in the future, so that it 
receives more publicity?


As I recall, the hope was for communication more often than every 
six months, and with more detail. Personally, I don't know if it 
would help. They're not involved with much outside of the 
language itself, and for the most part, the language is not D's 
problem.

[Issue 17559] New: [REG2.073.0] Wrong line number in stack trace

[via Digitalmars-d-bugs]

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

  Issue ID: 17559
   Summary: [REG2.073.0] Wrong line number in stack trace
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dlang-bugzi...@thecybershadow.net

/ test.d /
import mod;

void main()
{
fun(1);
fun(2);
fun(3);
fun(4);
}
// mod.d /
void fun(int n, int defParam = 10)
{
assert(n != 4);
}
//

Test command: dmd -g test.d mod.d ; ./test 2>&1 | grep _Dmain
Output with 2.072.2: test.d:8 _Dmain [0x427dc7]
Output with 2.073.0: test.d:5 _Dmain [0x427d37]

The correct line number is 8, not 5.

Introduced in https://github.com/dlang/dmd/pull/6327

--

Re: Checked vs unchecked exceptions

[Sebastien Alaiwan via Digitalmars-d]

On Monday, 26 June 2017 at 16:35:51 UTC, jmh530 wrote:
Just curious: how are checked exceptions different from setting 
nothrow as the default? Like you would have to write:


void foo() @maythrow
{
   functionWithException();
}

So for instance, you could still use your "//shut up compiler" 
code with the nothrow default.


Checked exceptions allow a lot more precision about what types of 
exceptions a function can throw.

Re: What are the unused but useful feature you know in D?

[Moritz Maxeiner via Digitalmars-d]

On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
On Mon, Jun 26, 2017 at 02:39:30PM +, Mike Parker via 
Digitalmars-d wrote:

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

> 
> So here's how I'd do it:
> 
> 1) Add the opposite attributes: `impure`, `throws`, `@gc`, 
> etc. 2) Add the module version thing that changes defaults 
> on request 3) imagine more potential going forward
> 
> 
> It isn't even hard.


And along with that a compiler switch to enable strict mode by 
default.


If you, or anyone else, is willing to put this in DIP form, 
I'll gladly do what I can to help minimize the effort required 
to write it up. This is something I'd love to see.


Yes, please do!  If we can push this through, D could be in a 
much, much better place in a few years' time!


As long as you don't introduce immutable by default, resulting in 
datastructures being littered with `mutable`.

Re: What are the unused but useful feature you know in D?

[Seb via Digitalmars-d]

On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
On Mon, Jun 26, 2017 at 02:39:30PM +, Mike Parker via 
Digitalmars-d wrote:

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

> 
> So here's how I'd do it:
> 
> 1) Add the opposite attributes: `impure`, `throws`, `@gc`, 
> etc. 2) Add the module version thing that changes defaults 
> on request 3) imagine more potential going forward
> 
> 
> It isn't even hard.


And along with that a compiler switch to enable strict mode by 
default.


If you, or anyone else, is willing to put this in DIP form, 
I'll gladly do what I can to help minimize the effort required 
to write it up. This is something I'd love to see.


Yes, please do!  If we can push this through, D could be in a 
much, much better place in a few years' time!


Actually, couldn't we use the same versioning mechanism for 
*most* of the proposed changes that are currently turned down 
because they would break too much code? Using this versioning 
would allow us to introduce breaking changes in an opt-in way, 
thus allowing codebases the needed time to migrate.



This idea is brillant!
We could use it to finally get rid off auto-decoding - a small 
PoC:


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

[Issue 17546] Cannot call .stringof on a function symbol if it does not have a no-args overload

[via Digitalmars-d-bugs]

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

--- Comment #3 from monkeywork...@hotmail.com ---
Ah, I forgot all about __traits(identifier). I wonder what the difference is
between this and .stringof... Anyway, this should be a good enough workaround
for the time being.

--

Re: Go 1.9

[Russel Winder via Digitalmars-d]

On Mon, 2017-06-26 at 16:30 +, jmh530 via Digitalmars-d wrote:
> 
[…]
> I don't know how well dub will handle it as my dub projects never 
> get this complicated. I haven't used SCons, but might make sense. 
> Reggae is another choice (though I haven't used that either).

Although I have been quite involved with SCons for a while, I am not
sure it is the future of build. Systems such as Meson/Ninja are much
nicer to work with.  Reggae is very much in the same camp as Meson. The
difference is that Meson has a big community giving it traction.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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

Re: Checked vs unchecked exceptions

[jmh530 via Digitalmars-d]

On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer 
wrote:


No, checked exceptions leads to this (maybe not for you, but 
for 90% of developers out there):


void foo()
{
   functionWithException();
}

compiler: foo throws, and you need to handle or declare the 
exceptions it throws


void foo()
{
   try {
 functionWithException();
   } catch(Exception e) {} // shut up compiler
}




Just curious: how are checked exceptions different from setting 
nothrow as the default? Like you would have to write:


void foo() @maythrow
{
   functionWithException();
}

So for instance, you could still use your "//shut up compiler" 
code with the nothrow default.

Re: Go 1.9

[jmh530 via Digitalmars-d]

On Monday, 26 June 2017 at 13:10:17 UTC, bachmeier wrote:


Thanks for giving it a try. I have a feeling that this is a job 
for Dub, SCons, or more likely, an R package that figures out 
this stuff. Windows development seems to have more moving 
parts. An R package on Linux requires adding a Makefile with 
one line.


I don't know how well dub will handle it as my dub projects never 
get this complicated. I haven't used SCons, but might make sense. 
Reggae is another choice (though I haven't used that either).

[Issue 13993] visual studio 2010: can't build with vcbuild/builddmd.bat

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
There's no longer a builddmd.bat, closing?

You can build a 64-bit dmd.exe with win64.mak if that's what you were after.

--

[Issue 16993] Documentation for toSimpleString and toString does not explain how they differ

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

  Component|dlang.org   |phobos
   Assignee|nob...@puremagic.com|issues.dl...@jmdavisprog.co
   ||m

--

Re: What are the unused but useful feature you know in D?

[H. S. Teoh via Digitalmars-d]

On Mon, Jun 26, 2017 at 02:39:30PM +, Mike Parker via Digitalmars-d wrote:
> On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
> 
> > 
> > So here's how I'd do it:
> > 
> > 1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
> > 2) Add the module version thing that changes defaults on request
> > 3) imagine more potential going forward
> > 
> > 
> > It isn't even hard.
> 
> And along with that a compiler switch to enable strict mode by
> default.
> 
> If you, or anyone else, is willing to put this in DIP form, I'll
> gladly do what I can to help minimize the effort required to write it
> up. This is something I'd love to see.

Yes, please do!  If we can push this through, D could be in a much, much
better place in a few years' time!

Actually, couldn't we use the same versioning mechanism for *most* of
the proposed changes that are currently turned down because they would
break too much code? Using this versioning would allow us to introduce
breaking changes in an opt-in way, thus allowing codebases the needed
time to migrate.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

[Issue 15646] Unresolved symbols when using m32mscoff with Windows subsystem

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86 |All

--- Comment #1 from Vladimir Panteleev  ---
For -m32mscoff or -m64, you need to link against user32.lib explicitly - either
add "user32.lib" to the compiler command line, or add pragma(lib, "user32") to
your program. I'm not sure why it's necessary only when targeting the MS
toolchain, though.

--

Re: dlang website design

[Seb via Digitalmars-d]

On Monday, 26 June 2017 at 12:59:56 UTC, bachmeier wrote:

On Monday, 26 June 2017 at 11:09:47 UTC, Mike Parker wrote:

On Monday, 26 June 2017 at 10:13:13 UTC, bachmeier wrote:

Now we have one, and by my count, the number of posts from 
Walter and Andrei are zero.


Actually, they have one each: Walter's "Snowflake Strings" [1] 
and Andrei's "Introspection, Introspection Everywhere" [2]


There are more in the pipeline, so we'll hear from them again 
a little ways down the road.


https://dlang.org/blog/2017/02/22/snowflake-strings/
https://dlang.org/blog/2017/05/22/introspection-introspection-everywhere/


Sorry, I was a bit sloppy. I meant posts from the perspective 
of leaders saying "this is the plan going forward". These are 
more of what I would consider technical posts rather than big 
picture plans for the future posts.


They publish a high-level vision every six months (e.g. 
https://wiki.dlang.org/Vision/2017H1) -maybe we should shoot out 
a short blog post about it in the future, so that it receives 
more publicity?

[Issue 16162] not reachable sites

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
Current status:

> https://dlang.org/ascii-table.html
> https://dlang.org/gsoc2012.html (and the others)
> https://dlang.org/howto-promote.html
> https://dlang.org/template-comparison.html
> https://dlang.org/tuple.html
> https://dlang.org/windbg.html
> https://dlang.org/wc.html
> https://dlang.org/dll-linux.html

Orphan

> https://dlang.org/deprecate.html

Linked from the documentation of the -d switch

> https://dlang.org/gpg_keys.html

Linked from the download page

> https://dlang.org/concepts.html

Linked from comparison page

> https://dlang.org/bugstats.php.html

Linked from menu (community -> issues)

--

[Issue 13598] enum isPublic(alias e) = __traits(getProtection, e) == "public";

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |DUPLICATE

--- Comment #1 from Vladimir Panteleev  ---
The example given compiles since https://github.com/dlang/dmd/pull/3841 was
merged, so I believe this to be a duplicate of issue 13226.

*** This issue has been marked as a duplicate of issue 13226 ***

--

[Issue 13226] Symbol is not accessible when using traits or mixin

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
*** Issue 13598 has been marked as a duplicate of this issue. ***

--

[Issue 17546] Cannot call .stringof on a function symbol if it does not have a no-args overload

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
(In reply to monkeyworks12 from comment #0)
> Currently I am resorting to a hacky workaround by doing
> `().stringof[2..$]`.

I've found another possible workaround:

__traits(identifier, test); // compile time literal of "test"

--

[Issue 17546] Cannot call .stringof on a function symbol if it does not have a no-args overload

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
Correction, test has to take a parameter:

int test(int)
{
   return 0;
}

Error message:
teststringof.d(8): Error: function teststringof.test (int _param_0) is not
callable using argument types ()
teststringof.d(8):while evaluating pragma(msg, (__error).stringof)

--

[Issue 12327] [IMPLEMENTATION] Target fields in frontend should be private to target.c

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Iain Buclaw from comment #0)
> There are a number of isXXX fields in mars.h (struct Params).

N.B. Today these are in src/ddmd/globals.h.

--

Re: Checked vs unchecked exceptions

[Ola Fosheim Grøstad via Digitalmars-d]

On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer 
wrote:

void foo()
{
   try {
 functionWithException();
   } catch(Exception e) {} // shut up compiler
}

So it ends up defeating the purpose. The exception is not 
properly handled, either inside or outside the function.


That's a poor argument, this will be caught in code reviews. You 
might as well use the same argument against returning error codes 
or optionals. Yes, it is possible to ignore them… and?

Re: Checked vs unchecked exceptions

[mckoder via Digitalmars-d]

On Monday, 26 June 2017 at 15:15:54 UTC, Steven Schveighoffer 
wrote:


No, checked exceptions leads to this (maybe not for you, but 
for 90% of developers out there):


void foo()
{
   functionWithException();
}

compiler: foo throws, and you need to handle or declare the 
exceptions it throws


void foo()
{
   try {
 functionWithException();
   } catch(Exception e) {} // shut up compiler
}



Why wouldn't you instead write:

void foo() throws Exception // shut up compiler
{
   functionWithException();
}

That's easier, and no worse than C# even though you have defeated 
checked exceptions.


Here's the point: with checked exceptions good programmers can 
write good code. Without checked exceptions even good programmers 
are forced to write bad code. It is impossible to prevent bad 
programmers from writing bad code, so that should not even be a 
goal, but enabling good programmers to write good code should be 
a goal.

Re: Checked vs unchecked exceptions

[Steven Schveighoffer via Digitalmars-d]

On 6/25/17 1:38 PM, mckoder wrote:

I am disappointed that D doesn't have checked exceptions.

C++ and C# also don't have checked exceptions. Java has checked 
exceptions. Having programmed extensively in all these languages I can 
say with confidence that checked exceptions is the most important thing 
missing in C++ and C#. Around the time C# was released there was a lot 
of debate around the topic of checked vs unchecked exceptions and this 
created an impression that Java's use of checked exceptions was 
"controversial". In fact it is a feature every modern language should have.


No, checked exceptions leads to this (maybe not for you, but for 90% of 
developers out there):


void foo()
{
   functionWithException();
}

compiler: foo throws, and you need to handle or declare the exceptions 
it throws


void foo()
{
   try {
 functionWithException();
   } catch(Exception e) {} // shut up compiler
}

So it ends up defeating the purpose. The exception is not properly 
handled, either inside or outside the function.


You can get into a long discussion if you want, I'm not going there. 
Bottom line: D *will not* have checked exceptions, Walter has said so 
many times. If that's a deal killer, you should probably stick with 
Java. Sorry, don't want to waste your time.


-Steve

Re: Project Highlight: Derelict

[Mike Parker via Digitalmars-d-announce]

On Monday, 26 June 2017 at 14:55:25 UTC, arturg wrote:



s/you don't tend find/you don't tend to find/

s/As the D has evolved/As D has evolved/


Thanks!

Re: Checked vs unchecked exceptions

[mckoder via Digitalmars-d]

On Sunday, 25 June 2017 at 18:00:46 UTC, Eugene Wissner wrote:

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



As suggested by the post in above link I searched for "Walter 
checked exceptions". I found a few posts where Walter points to 
an article written by Bruce Eckel. Though the link to Eckel's 
article no longer works, I am familiar with Eckel's arguments, 
and I even exchanged emails with Eckel back in 2003 on this 
topic. Suffice to say I believe Eckel is wrong on this topic.


Bruce Eckel argues that checked exceptions forces you to write 
bad code (catch Exception base class) and Walter mentions this. 
Eckel is wrong. The opposite is true. Lack of checked exceptions 
forces you to catch Exception base class in order to prevent 
crashes. If you know what exceptions are possible then you can 
catch just those exceptions. If you don't know then you have to 
rely on testing to find out what exceptions are possible but you 
will never get an exhaustive list through testing since tests can 
never be 100% comprehensive for non-trivial programs. So you end 
up catching Exception base class, thus swallowing exceptions. I 
have seen lots of large code bases in C# and Java written by very 
good developers, and I can tell you that experience has proven 
that "catch (Exception)" is common in C# code bases and rarely 
seen in Java code bases.

[Issue 17519] RedBlackTree doesn't like const/immutable elements

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/29c7f36df591e3137233460940cdd824a745786c
fix issue 17519 - RedBlackTree doesn't like const/immutable elements

https://github.com/dlang/phobos/commit/173ccd835b5080dde5eec00d0ddae35a954b87cd
Merge pull request #5492 from aG0aep6G/rbtree-immutable

--

Re: Project Highlight: Derelict

[arturg via Digitalmars-d-announce]

On Monday, 26 June 2017 at 14:30:13 UTC, Mike Parker wrote:
I've just published a wall of text about Derelict. I don't 
think I've ever written so much about it in one sitting, so it 
was a fun post to write. As well as (the reminder of how fast 
time is slipping away aside) a nice walk down memory lane.


The Blog:
https://dlang.org/blog/2017/06/26/project-highlight-derelict/

Reddit:
https://www.reddit.com/r/programming/comments/6jldos/derelict_a_collection_of_d_bindings_to_c_libraries/


s/you don't tend find/you don't tend to find/

s/As the D has evolved/As D has evolved/

Re: D Milestones

[Martin Tschierschke via Digitalmars-d]

On Monday, 26 June 2017 at 12:58:00 UTC, Andrea Fontana wrote:
On Monday, 26 June 2017 at 10:14:08 UTC, Martin Tschierschke 
wrote:
I think it would be good for all which want to invest their 
time in learning D to know more about the history and probably 
the future of D.


D frontend written in d?

Yes this was exactly when I got aware of D!

[Issue 7182] Call const or immutable member functions from class invariant

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Infiltrator from comment #1)
> I think that the issue would instead be with the fact that public functions
> (f() in this case) call invariant() before and after they run, which would
> result in an infinite loop.

Pretty sure your explanation is correct.

Although one may argument in favor of making const methods not cause invariant
checks, that would mean that e.g. getters are no longer protected by
invariants, should something modify the object's state into an invalid one
directly (e.g. by writing to fields).

--

[Issue 13627] Error: core.stdc.string.memcpy conflicts with core.thread.memcpy

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
core.thread today no longer mentions memcpy, so I assume this is no longer an
issue.

--

Re: What are the unused but useful feature you know in D?

[Mike Parker via Digitalmars-d]

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:



So here's how I'd do it:

1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on request
3) imagine more potential going forward


It isn't even hard.


And along with that a compiler switch to enable strict mode by 
default.


If you, or anyone else, is willing to put this in DIP form, I'll 
gladly do what I can to help minimize the effort required to 
write it up. This is something I'd love to see.

Project Highlight: Derelict

[Mike Parker via Digitalmars-d-announce]

I've just published a wall of text about Derelict. I don't think 
I've ever written so much about it in one sitting, so it was a 
fun post to write. As well as (the reminder of how fast time is 
slipping away aside) a nice walk down memory lane.


The Blog:
https://dlang.org/blog/2017/06/26/project-highlight-derelict/

Reddit:
https://www.reddit.com/r/programming/comments/6jldos/derelict_a_collection_of_d_bindings_to_c_libraries/

[Issue 16462] mixin template ddoc doesn't appear in docs

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #3 from Vladimir Panteleev  ---
It's the same as with any other composite declaration - you have to document
the top-level declaration so that the nested declarations are rendered. E.g.
here the documentation will be blank:

struct S
{
/// foo
int foo;
}

So, it's not specific to mixin templates.

Not sure if it's by design or not, but in any case, having a composite
declaration without documentation with members that do have documentation in it
might look weird at least in some DDoc themes.

Closing this seeing as there was some confusion as to the nature of the bug and
a workaround has been fonud; please reopen or file a new bug if you have a use
case for doing the above.

--

Re: range of ranges into one range?

[Jonathan Marler via Digitalmars-d-learn]

On Monday, 26 June 2017 at 06:19:07 UTC, rikki cattermole wrote:

Perhaps?
http://dlang.org/phobos/std_algorithm_iteration.html#.joiner


Thank you.

Re: What are the unused but useful feature you know in D?

[Adam D. Ruppe via Digitalmars-d]

On Monday, 26 June 2017 at 04:31:33 UTC, H. S. Teoh wrote:

Yes, the wrong defaults were a historical accident.


One that we could fix, even without breaking any code.

Of course, breaking some code to change it would be fairly 
straightforward to fix for authors, and could even be done 
automatically in theory (something like dfix), but there's 
another solution too: opt in once per module, then change things. 
Javascript did this to pretty good success with its "use strict" 
thing.


---
// status quo D
module foo.bar;

@safe void whatever() {}
---

---
// next gen D
module version(3.0) foo.bar; // opt in here
void whatever() {} // now @safe by default
---


The syntax could be whatever, but inside the compiler, when it 
detects that, it switches around the default for the module. 
Being opt in means only maintained files get it, but being single 
point change means it is easy to do.


And since changes like this can easily live side by side with 
other modules, it provides a simple path forward.



So here's how I'd do it:

1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on request
3) imagine more potential going forward


It isn't even hard.

[Issue 13335] Add rotateTail to std.algorithm and formally define sameHead

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P3
  Component|dmd |phobos
   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 15504] core.demangle uses exception handling for normal control flow

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||dlang-bugzilla@thecybershad
   ||ow.net

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Walter Bright from comment #0)
> https://github.com/D-Programming-Language/druntime/blob/master/src/core/
> demangle.d

Permalink to that day's version:
https://github.com/dlang/druntime/blob/43a7e6830980cd242c1fbae145cffdf7be397069/src/core/demangle.d

To find the offending code, search for catch(...) blocks.

Permalink to today's version, which still has the problematic code:
https://github.com/dlang/druntime/blob/68ba136a3ce7ff9c66580b2efd659a27aa035dd8/src/core/demangle.d

--

[Issue 17202] std.functional: partialRight

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P1  |P5
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 10728] A combination of implicit conversion and lambda call cannot be compiled

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
In D2, use .idup to create a copy of an immutable string.

The result of .dup will implicitly convert to a string in some circumstances as
a convenience feature to ease migration from D1. It works because the compiler
knows that although the result of .dup is mutable, it is also unique. However,
this inference is limited by design.

--

[Issue 13153] dlang.org: provide version-specific documentation of the language and stdlib

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Vladimir Panteleev  ---
*** Issue 15810 has been marked as a duplicate of this issue. ***

--

[Issue 15810] Store historical docs

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |DUPLICATE

--- Comment #2 from Vladimir Panteleev  ---


*** This issue has been marked as a duplicate of issue 13153 ***

--

Re: past.code123.org new service for sharing D code.

[Suliman via Digitalmars-d-announce]

On Saturday, 24 June 2017 at 12:59:50 UTC, Suliman wrote:
Sorry! Domain should be not `past` `but` `paste` 
http://paste.code123.org/


version 0.2
split-view support: http://paste.code123.org/86fc5ded-90e1

P.S. WIP

[Issue 9567] "Symbol Undefined" linker error after separating project part into library

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
Closing, as there has been no reply in over 2 years.

If you can provide a complete self-contained test case starting from D source
code, please reopen.

--