Re: Finding source of typeid use

[rikki cattermole via Digitalmars-d-learn]

On 08/07/2017 2:35 AM, Nicholas Wilson wrote:

On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:

My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))

[...]


It seems to be coming from the need to hash the type, goodness knows 
why, which explains why I only get the const variety.


https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe?

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #3 from Jonathan M Davis  ---
I'm very tempted to close this as "won't fix." Here's a semi-recent discussion
on this issue:

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

and this is probably my best post in there about why general exception types
like this are a bad idea:

http://forum.dlang.org/post/mailman.1239.1490287548.31550.digitalmar...@puremagic.com

Andrei did not weigh in on the topic, but Walter was in clear agreement with me
that this sort of approach is a bad idea.

--

Re: Application settings

[bauss via Digitalmars-d-learn]

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

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

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
What's the "best" way to do this? I want something I can 
simply load at startup in a convenient and easy way then save 
when necessary(possibly be efficient at it, but probably 
doesn't matter).


Simply json an array and save and load it, or is there a 
better way?


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


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



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


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


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

Re: Release fluent-asserts 0.6.0

[Jay Norwood via Digitalmars-d-announce]

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


Any feedback is appreciated.

Thanks,
Bogdan


Hi,  if you're just looking for other ideas, you might want to 
look at adding capabilities like in the java hamcrest matchers.  
You might also want to support regular expression matches in the 
string matchers.


http://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/Matchers.html

These were used in swtbot, which made a very nice testing 
environment for their swt gui widgets.  Swtbot added filtering 
for the context of the match as well.  You can get a feel for it 
in this article.  There is a DWT library translated from java 
swt, but this testing app wasn't ported.


http://www.vogella.com/tutorials/SWTBot/article.html

Re: DCompute development

[Nicholas Wilson via Digitalmars-d]

On Wednesday, 5 July 2017 at 18:48:57 UTC, Luís Marques wrote:
On Wednesday, 5 July 2017 at 09:41:40 UTC, Nicholas Wilson 
wrote:
Now that I've (finally) finished my honours thesis, I've got 
time to start working on dcompute again. I'd like to invite 
anyone interested in helping to develop and/or document (or 
just interested in general) the drivers for OpenCL/CUDA, the 
device standard library and other stuff. Please post here or 
on the MIR gitter (https://gitter.im/libmir/public) if you 
would like to contribute.


I would like to contribute. Is it possible to provide some 
small chunked tasks to begin with? I have limited time and 
attention span right now, so that would help a lot.


Thanks, I try and subdivide and further flesh out 
https://github.com/libmir/dcompute/projects

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

[FoxyBrown via Digitalmars-d]

On Saturday, 8 July 2017 at 02:23:53 UTC, Jonathan M Davis wrote:
On Saturday, July 8, 2017 12:55:46 AM MDT FoxyBrown via 
Digitalmars-d wrote:
I came across some error in heap sort. Was erroring out on the 
wrong. A few lines below the assert existed but no error 
message associated, why is it so hard to not write a few extra 
EXTREMELY helpful error messages?


assert(isHeap(r), "This is an ERROR AT THIS
LOCATION"~__FILE__~"("~__LINE__~")");

etc?

It should be mandatory that all asserts, throws, etc provide 
correct information about not only the point of the error but 
also the location and what caused it. These things are not 
irrelevant but affect all those that use it... imagine the 
real human man hours that could be saved if such things were 
done.


It would be easy to find all the bad asserts?


AssertError already provides the location of the assertion, and 
it uses __FILE__ and __LINE__ to do it (_all_ Exception types 
do that unless the person who wrote the class screwed up the 
constructor), so adding them to the message it pointless and 
redundant. If the assertion failure is printing out the wrong 
line, then it's likely either because you're looking at the 
wrong version of the code or because a string mixin is screwing 
with the line numbers (which IMHO, shouldn't happen, but it at 
least used to be a problem).


In addition, the AssertError should be giving you a stack 
trace, which _should_ have the file and line numbers in it of 
every call in the stack (though stupidly, the line numbers 
don't always work, depending on your OS).


So, you _should_ have had that information by the simple fact 
that an AssertError was thrown, and unless the assertion itself 
needed additional explanation beyond the condition that failed, 
then a message wouldn't have helped anyway.


So, if the file and line number was wrong, the question is why, 
and that should be fixed. And we really need to figure out how 
to make it so that the issue of not having line numbers with 
stack traces goes away and stays away. The fact that it's been 
a problem is ridiculous, because file and line numvbers in 
stack traces are critical for debugging.


- Jonathan M Davis


But you miss the complete point, You focused on what D does 
rather than what it doesn't, which is what lead me to the problem 
in the first place. You are seeing the glass half full, rather 
than half empty, my friend.


Shall I explain it so it makes sense? I was writing a natural 
sorting routine so I could get some string array sorted. This is 
because D is missing the capabilities to do a natural sort 
correctly. It does not compare the the integer in string a with 
the matching integer in string B correctly. If they happen to be 
a different length then it assumes the shorter one was smaller. 
At least, when I tried it, that is what I remember being the 
problem, or some other weird behavior, but it was not correct. 
Therefore, I decided to write the natural sorting routine to fix 
that(This is because I am a person that wants to drink a full 
glass of water rather than an empty glass).


To implement the algorithm is rather simple in some ways and 
complicated in others.



string[] naturalSort(string[] arr) /*pure @safe*/
{
alias myComp = (x, y) {
   return ComplexPart(x,y);
};

auto x = arr.sort!(myComp).release;
return x;
}

bool ComplexPart(string x, string y)
{
auto ml = cast(int)(min(x.length, y.length)-1);
auto ofsX = -1; auto ofsY = -1;
auto numX_found = -1;
auto numY_found = -1;
for(int i = 0; i <= ml; i++)
{
// If one string is left slice of the other, it wins
			if (i >= ml || ofsX >= ml || ofsY >= ml) { if (x.length < 
y.length) return true; return false; }


ofsX++;
ofsY++;

// If characters are not a digit, use default comparer
if (!isDigit(x[ofsX]) || !isDigit(y[ofsY]))
{
if (x[ofsX] != y[ofsY])
return x[ofsX] < y[ofsY];
continue;
}

			// We now know that x and y are identical up to the digit 
sequence. Extract these sequences then compare, if identical *in 
value*(000 = 0, etc) we continue the compare, else we compare 
the numbers and use that to specify the comparision quality

while (ofsX < ml && isDigit(x[ofsX])) { ofsX++; };
while (ofsY < ml && isDigit(y[ofsY])) { ofsY++; };

auto numX = x[i..ofsX];
auto numY = y[i..ofsY];

auto res = compareStringNum(numX, numY);
if (res != 0)
return (res != 1);
  

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

[Jonathan M Davis via Digitalmars-d]

On Saturday, July 8, 2017 12:55:46 AM MDT FoxyBrown via Digitalmars-d wrote:
> I came across some error in heap sort. Was erroring out on the
> wrong. A few lines below the assert existed but no error message
> associated, why is it so hard to not write a few extra EXTREMELY
> helpful error messages?
>
> assert(isHeap(r), "This is an ERROR AT THIS
> LOCATION"~__FILE__~"("~__LINE__~")");
>
> etc?
>
> It should be mandatory that all asserts, throws, etc provide
> correct information about not only the point of the error but
> also the location and what caused it. These things are not
> irrelevant but affect all those that use it... imagine the real
> human man hours that could be saved if such things were done.
>
> It would be easy to find all the bad asserts?

AssertError already provides the location of the assertion, and it uses
__FILE__ and __LINE__ to do it (_all_ Exception types do that unless the
person who wrote the class screwed up the constructor), so adding them to
the message it pointless and redundant. If the assertion failure is printing
out the wrong line, then it's likely either because you're looking at the
wrong version of the code or because a string mixin is screwing with the
line numbers (which IMHO, shouldn't happen, but it at least used to be a
problem).

In addition, the AssertError should be giving you a stack trace, which
_should_ have the file and line numbers in it of every call in the stack
(though stupidly, the line numbers don't always work, depending on your OS).

So, you _should_ have had that information by the simple fact that an
AssertError was thrown, and unless the assertion itself needed additional
explanation beyond the condition that failed, then a message wouldn't have
helped anyway.

So, if the file and line number was wrong, the question is why, and that
should be fixed. And we really need to figure out how to make it so that the
issue of not having line numbers with stack traces goes away and stays away.
The fact that it's been a problem is ridiculous, because file and line
numvbers in stack traces are critical for debugging.

- Jonathan M Davis

DIP 1007--"future symbol"--Has Been Accepted

[Mike Parker via Digitalmars-d-announce]

Congratulations to Mihails Strasuns, a.k.a. Dicebot, on the acceptance 
of his DIP 1007, '"future symbol" Compiler Concept'!


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

Although the proposal recommended that the feature be implemented only 
internally for DRuntime initially, Walter felt that isn't necessary. So 
once implemented, the feature will be available for immediate use. 
Thanks are due to Sociomantic, particularly Leandro Lucarella, who 
answered Walter's questions on Sociomantic's usage of the feature in 
their code base.


In other DIP news, I'm tentatively planning to merge DIP 1011 and begin 
its preliminary review in the coming week. This is going to be the 
"extern(delegate)" proposal from Jonathan Marler. I invite everyone to 
participate in the draft review on the PR over the next few days.


https://github.com/dlang/DIPs/pull/74

Another DIP in the queue in need of a draft review is Nicholas Wilson's 
proposal to allow changing the default attributes (like @system vs. 
@safe, @nogc vs. 'uses GC'). This DIP follows on from a recent 
discussion here in the forums. The sooner we can get feedback on the PR, 
the sooner I'll be ready to merge it and begin the review process.


https://github.com/dlang/DIPs/pull/75

Finally, I find that DIP 1010, Timon Gehr's "static foreach", received 
no external input in the draft review, and no feedback during the 
preliminary review -- the discussion thread is empty! Either it was 
completely ignored or it's so well put together that it warrants no 
criticism. I'm inclined to believe that it's the latter. With that in 
mind, I'm going to push it on to the formal review without the normal 
two-week window for feedback. I'll make the announcement on Monday, then 
if there is no feedback by Wednesday that warrants keeping it open, I'll 
submit it to Walter and Andrei for judgement. So please read the DIP if 
you haven't already and consider over the weekend if you have anything 
to say about it. If so, then you can post it in the thread I'll open on 
Monday.


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

[Issue 9693] unclear scoping behaviour of declarations made in static if conditions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--

[Issue 15373] Segfault when using typeid on extern(C++) class with virtual functions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid, C++

--

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

[Jonathan M Davis via Digitalmars-d]

On Saturday, July 8, 2017 1:51:34 AM MDT Moritz Maxeiner via Digitalmars-d 
wrote:
> On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote:
> > [...]
> > It should be mandatory that all asserts, throws, etc provide
> > correct information about not only the point of the error but
> > also the location and what caused it. [...]
>
> Error messages are sensible when they provide context (e.g. for
> complex conditions).
> In my experience, though, most asserts exist to cover fairly
> obvious cases, where an additional message would just add noise:
>
> ---
> struct SomeRange
> {
>  bool empty() { ... }
>  void popFront()
>  {
>  assert (!empty);
>  ...
>  }
> }
> ---

I tend to agree - in many cases, the error message is completely redundant -
but a number of folks seem to think that you should never have an assertion
without a message, and it tends to get complained about if you have an
assertion without a message if it's not in a unit test, so I'm a bit
surprised that the OP ran into one in Phobos.

- Jonathan M Davis

[Issue 15640] type inference in variadic array params not working for classes

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

Re: Automatic invariant generation

[Jonathan M Davis via Digitalmars-d]

On Friday, July 7, 2017 2:31:42 PM MDT Nicholas Wilson via Digitalmars-d 
wrote:
> On Friday, 7 July 2017 at 14:17:34 UTC, Jonathan M Davis wrote:
> > What does it even do?
>
> asserts that the this pointer is not null, apparently which is
> annoying because you'd crash anyway. I suppose you might get a
> nicer error message but it doesn't add much.
>
> > I don't see how it makes any sense for _anything_ to have an
> > invariant if it's not explicitly declared.
>
> Worse I can't even @disable it because thats a syntax error.
>
> > And honestly, I'm of the opinion that invariants with structs
> > are borderline useless, because they're run even before
> > opAssign, meaning that if you ever need to use = void; or use
> > emplace, then you're screwed if you have an invariant, because
> > it's bound to fail due to the object not having been
> > initialized previously.
>
> Huh, I didn't know that.

I was not pleased to find out about it either, and the result is that I tend
to think that invariants have no business being in structs, much as it would
be desriable for them to be there.

> That does seems to be purpose defeating zealotry.

It's desirable when the object is supposed to be in a good state, because
then you know that when you do the assignment, you'll catch if something
broke the invariant before the assignment. But it's completely undesirable
when the object was purposely uninitialized, and since you can't choose
whether the invariant is run or not, IMHO, _not_ running it would be better,
but I was not persuasive enough:

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

I was discussing this issue with someone at dconf, and as a result of that
conversation, I've considered writing a DIP that would allow you to
explicitly skip calling an invariant on a specific assignment (since in
theory, you should know when you're assigning to an unitialized object), but
I haven't had the time to think it through completely, let alone put
together a DIP that might actually be persuasive.

- Jonathan M Davis

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

[Mike Parker via Digitalmars-d-announce]

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

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


It's already there under:

version (DigitalMars)


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

[Issue 15140] std.experimental.allocator.building_blocks.free_list.FreeList leaks memory

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||and...@erdani.com

--

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

[Moritz Maxeiner via Digitalmars-d]

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

[...]
It should be mandatory that all asserts, throws, etc provide 
correct information about not only the point of the error but 
also the location and what caused it. [...]


Error messages are sensible when they provide context (e.g. for 
complex conditions).
In my experience, though, most asserts exist to cover fairly 
obvious cases, where an additional message would just add noise:


---
struct SomeRange
{
bool empty() { ... }
void popFront()
{
assert (!empty);
...
}
}
---

[Issue 11405] rdmd should limit its tmp cache

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

  Component|dmd |tools

--- Comment #3 from Vladimir Panteleev  ---
With /tmp being a tmpfs on many distros today, and Windows' disk cleanup
utility knowing about and deleting the %TEMP% directory on request or when the
disk gets full, this may not be as much of an issue nowadays, though still may
be worth fixing.

--

Re: Release candidates vibe.d 0.8.0-rc.6 and vibe-core 1.0.0-rc.4

[Sönke Ludwig via Digitalmars-d-announce]

There have been two more regression fixes:

- (De)serialization of self-referential types was broken (@safe related 
compile error)

- The .parentPath property of the new path types in vibe-core was broken

The release date is still scheduled for Monday.

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

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||C++
   Hardware|x86_64  |All

--

[Issue 15587] Enable use of D keywords as identifiers when interfacing to C/C++

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
In this particular case, the easiest workaround is to use pragma(mangle),
right?

I understand that this is more useful for C++ functions, whose mangling is
non-trivial.

--

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

[Seb via Digitalmars-d]

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

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

It would be easy to find all the bad asserts?


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


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

Re: Finding source of typeid use

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:

My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))

[...]


It seems to be coming from the need to hash the type, goodness 
knows why, which explains why I only get the const variety.

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

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Jacob Carlborg from comment #1)
> Not sure why it's called "stat_t" in the D version when it's
> called "stat" in the C headers.

It's because in C, "stat" is both the name of a struct and a function. This is
not a problem for C because structs in C have their own namespace (unless you
typedef them), but there is no equivalent in D.

There are some workarounds available:

- You can use extern(C) to link the D declaration with the C definition. As
argument types are not mangled with C linkage, type name mismatches will not
result in a link error.
- You can use pragma(mangle) on the D side to directly override a function's
mangled name;
- Finally, on the D side you could declare the function as:

struct stat;
void myFunc(stat*){}

then cast the stat_t* to stat* when invoking the function.

As this is not a bug in D and simple workarounds exist, I'll close this, but
feel free to reopen if you can present actionable ideas for improving the
situation.

--

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

[Walter Bright via Digitalmars-d-announce]

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


It's already there under:

version (DigitalMars)

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

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

On Fri, Jul 07, 2017 at 07:12:28PM -0600, Jonathan M Davis via 
Digitalmars-d-announce wrote:
> On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d-
> announce wrote:
[...]
> > The implicit slice is one of what I see as D's design flaws and
> > brings up a number of problems. dip1000 and similar things might be
> > able to fix the problems without changing the feature, but I won't
> > be surprised if after a couple more years, we see that implicit
> > slice get deprecated.

I'm also against implicit slicing of static arrays. It's just too
dangerous, and also interacts poorly with template functions.


> The trick is convincing Walter. The last time I brought it up with
> him, he thought that improvements to @safe would fix the problem - and
> they will help - but it interacts badly with templated code, and I
> think that from a code clarity standpoint, the slicing needs to be
> explicit. So, I'm of the opinion that implicit slicing should simply
> be deprecated regardless of the state of @safe, but I don't know how
> possible it is to convince Walter of that. Fixing the @safe issues is
> at least a start though.
[...]

It's true that fixing @safe issues will at least reduce the problem
surface of implicit slicing. But it's like bandaid over a festering
wound; the problem is still there, it just lurks in more obscure corners
now.


T

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

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

[Timon Gehr via Digitalmars-d]

On 08.07.2017 02:55, FoxyBrown wrote:
I came across some error in heap sort. Was erroring out on the wrong. A 
few lines below the assert existed but no error message associated, why 
is it so hard to not write a few extra EXTREMELY helpful error messages?


assert(isHeap(r), "This is an ERROR AT THIS 
LOCATION"~__FILE__~"("~__LINE__~")");


etc?

It should be mandatory that all asserts, throws, etc provide correct 
information about not only the point of the error but also the location 
and what caused it. These things are not irrelevant but affect all those 
that use it... imagine the real human man hours that could be saved if 
such things were done.


It would be easy to find all the bad asserts?


It think the main issue is that the assertion failure had the wrong 
location information. This is not supposed to happen. Do you have a 
small example that demonstrates the issue?



I think that as long as the location is correct, the rest can be 
reconstructed without wasting a lot of time. (Of course, this is no 
excuse for Phobos not providing a more informative error message.)

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

[Jonathan M Davis via Digitalmars-d-announce]

On Friday, July 7, 2017 1:48:47 PM MDT Adam D. Ruppe via Digitalmars-d-
announce wrote:
> I would add a note to the "static arrays are interchangeable with
> dynamic arrays" saying that you can... and probably should
> explicitly slice them with `[]`.
>
> The implicit slice is one of what I see as D's design flaws and
> brings up a number of problems. dip1000 and similar things might
> be able to fix the problems without changing the feature, but I
> won't be surprised if after a couple more years, we see that
> implicit slice get deprecated.

The trick is convincing Walter. The last time I brought it up with him, he
thought that improvements to @safe would fix the problem - and they will
help - but it interacts badly with templated code, and I think that from a
code clarity standpoint, the slicing needs to be explicit. So, I'm of the
opinion that implicit slicing should simply be deprecated regardless of the
state of @safe, but I don't know how possible it is to convince Walter of
that. Fixing the @safe issues is at least a start though.

- Jonathan M Davis

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

[Vladimir Panteleev via Digitalmars-d]

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

It would be easy to find all the bad asserts?


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

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

[FoxyBrown via Digitalmars-d]

I came across some error in heap sort. Was erroring out on the 
wrong. A few lines below the assert existed but no error message 
associated, why is it so hard to not write a few extra EXTREMELY 
helpful error messages?


assert(isHeap(r), "This is an ERROR AT THIS 
LOCATION"~__FILE__~"("~__LINE__~")");


etc?

It should be mandatory that all asserts, throws, etc provide 
correct information about not only the point of the error but 
also the location and what caused it. These things are not 
irrelevant but affect all those that use it... imagine the real 
human man hours that could be saved if such things were done.


It would be easy to find all the bad asserts?

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

[Nicholas Wilson via Digitalmars-d-announce]

On Friday, 7 July 2017 at 22:42:08 UTC, Walter Bright wrote:

On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
Since it's an intrinsic (as confirmed by you), maybe we can 
just drop the version conditions? The compiler will always 
generate it, regardless of C lib, right? I'll do the PR if you 
agree (just want to make sure I understand your statements 
about it).


DMD will. I don't know about LDC or GDC.


It's an intrinsic in LDC. We can certainly drop the per platform 
and move to a per compiler definition instead.

[Issue 5276] Template compilation uses much more memory than G++ 4.8

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #5 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/2239 - compilation is under one
second now.

--

Re: Application settings

[FoxyBrown via Digitalmars-d-learn]

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

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
What's the "best" way to do this? I want something I can 
simply load at startup in a convenient and easy way then save 
when necessary(possibly be efficient at it, but probably 
doesn't matter).


Simply json an array and save and load it, or is there a 
better way?


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


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



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

[Issue 5276] Template compilation uses much more memory than G++ 4.8

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--

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

[Walter Bright via Digitalmars-d-announce]

On 7/7/2017 1:33 PM, Steven Schveighoffer wrote:
Since it's an intrinsic (as confirmed by you), maybe we can just drop the 
version conditions? The compiler will always generate it, regardless of C lib, 
right? I'll do the PR if you agree (just want to make sure I understand your 
statements about it).


DMD will. I don't know about LDC or GDC.

Foster parents for Phobos modules wanted

[Seb via Digitalmars-d]

With which Phobos module(s) are you most familiar with?

-> https://github.com/dlang/phobos/pull/5573

Being on the Phobos team is _not_ a requirement - everyone can 
help out!

[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

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

   What|Removed |Added

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

--

[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 #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable 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

Fix issue 17482: Fix Nullable!Variant equality checks.
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 10185] Linker errors with rdmd

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #1 from Vladimir Panteleev  ---
Fairly sure this has since been fixed, as rdmd has receieved a ton of
reliability improvements since 2013. Please reopen if you can still reproduce
this.

--

Re: Application settings

[aberba via Digitalmars-d-learn]

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
What's the "best" way to do this? I want something I can simply 
load at startup in a convenient and easy way then save when 
necessary(possibly be efficient at it, but probably doesn't 
matter).


Simply json an array and save and load it, or is there a better 
way?


Ideally, I'd like to store the settings as part of the binary 
to keep everything together but that poses a few issues I think.


Setting are not kept in binary (usually). Normally the installer 
would take care of creating a folder somewhere with a 
JSON/XML/SQlite file which stores settings.

[Issue 5077] std.algorithm.schwartzSort is slow

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--- Comment #6 from Vladimir Panteleev  ---
Still reproducible in 2017.

FWIW, with LDC, the difference is smaller: only schwartzSort is slower than
regular sort only by about one third rather than being about twice as slow.

--

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

[via Digitalmars-d-bugs]

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

--- Comment #6 from Andrei Alexandrescu  ---
@Temtaime should this stay open?

--

Re: Vibe.d - very low performance

[Sönke Ludwig via Digitalmars-d]

Am 07.07.2017 um 21:27 schrieb FoxyBrown:

On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote:

Am 06.07.2017 um 09:27 schrieb Marek:

https://www.techempower.com/benchmarks/#section=data-r14=ph=plaintext



C++, Java and Go frameworks have very high performance. Vibe.d is
supposed to have similar performance, but in fact vibe.d performance
is very low. Why?


This is a scalability issue, which should hopefully be fixed with
0.8.0. I'll open a PR once that is out. Basically with the version
that was used in the last benchmark round, it didn't scale at all, and
they use a server with many cores (40 + hyperthreading).


So you are saying that will solve the nearly 200x factor from the top?
At least get it in the top 20?


There are more factors involved, but just based on this I would expect a 
factor of around x50 (~>800k/s). The 15k/s is very low even for a single 
core, though, and it's very possible that the factor will be 
considerably larger. However, this is hard to predict, as I currently 
don't have access to similar hardware to test this on.

[Issue 12372] Forward reference error with auto type inference in overloaded functions

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--- Comment #1 from Vladimir Panteleev  ---
Fixed by https://github.com/dlang/dmd/pull/5202.

--

Re: Automatic invariant generation

[ketmar via Digitalmars-d]

Steven Schveighoffer wrote:


On 7/7/17 4:26 PM, ketmar wrote:

Steven Schveighoffer wrote:


On 7/7/17 2:27 PM, ketmar wrote:

ketmar wrote:

yeah, this is annoying. while checking for "null this" in *class* 
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class 
methods, but this is a completely different story.


In *final* methods maybe. Virtual methods are going to crash anyway 
before they get to that point.
i meant "in manual checking", i.e. "i think that compiler-inserted 
`assert` is not necessary at all". sorry for writing indecipherable 
engrish. ;-)


My statement still applies ;)


yeah ;-)

Re: Application settings

[Moritz Maxeiner via Digitalmars-d-learn]

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
What's the "best" way to do this? I want something I can simply 
load at startup in a convenient and easy way then save when 
necessary(possibly be efficient at it, but probably doesn't 
matter).


Simply json an array and save and load it, or is there a better 
way?


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


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

Re: Automatic invariant generation

[Steven Schveighoffer via Digitalmars-d]

On 7/7/17 4:26 PM, ketmar wrote:

Steven Schveighoffer wrote:


On 7/7/17 2:27 PM, ketmar wrote:

ketmar wrote:

yeah, this is annoying. while checking for "null this" in *class* 
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class 
methods, but this is a completely different story.


In *final* methods maybe. Virtual methods are going to crash anyway 
before they get to that point.


i meant "in manual checking", i.e. "i think that compiler-inserted 
`assert` is not necessary at all". sorry for writing indecipherable 
engrish. ;-)


My statement still applies ;)

-Steve

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Friday, 7 July 2017 at 18:48:31 UTC, Marco Leise wrote:

Am Thu, 06 Jul 2017 13:16:23 +
schrieb Moritz Maxeiner :

That's right, but still one can distill general ideas and leave 
implementations details aside. Pretty much like the Platonic 
Ideal. Then you look at what the complaints are with the 
current implementation and see if you can satisfy all sides.


The requirement checked exceptions impose on all functions to 
declare their respective exception set is not an implementation 
detail, but part of the definition.
With regards to the general ideas: That's what my writing about 
exception sets, tehir inference, and nothrow analysis were 
(supposed to be) about.
Unless, however, whatever one eventually tries to get into the 
language (if that is even attempted) conforms to the preexisting 
definition of checked exceptions (which I'm as certain as I can 
reasonably be won't make it into D), calling it that will only 
serve to cloud the issue and alienate people.
Personally, I would call a system with the exception set of a 
function being (optionally) declarable as "declarable 
exceptions", but that might still be too close to "checked 
exceptions" not to illicit screams of horror.




[...]

I.e. everything stays the same until a programmer needs a 
verification of what (s)he should/could handle right away, what 
needs to be wrapped and what can be passed further up the call 
chain. That's close to impossible now in deeply nested code.


If one replaces the `@check_exceptions` with `nothrow` the above 
is essentially what one should get if one enhances the (static) 
nothrow analysis (as I mentioned in an earlier post) to 
essentially treat a scope implicitly as nothrow if the aggregated 
exception set (as determined by the compiler) is empty.

Or more succinct: Infer `nothrow` for normal functions, as well.

In other cases an exception is only thrown when an incorrect 
argument is passed. Knowing (statically) that you pass only 
good values you can catch the exception and turn it into an 
assert instead of passing it up the call chain, potentially 
allowing the caller to be nothrow.


There are two cases here:
 - the function takes untrusted user data:
   Violations are valid runtime behaviour -> Exceptions, error 
codes, split in validation and processing function pair with the 
second being executed only after the first has successfully 
validated the input data (and thus transformed it into trusted 
program data), etc.

 - the function takes trusted program data:
   Violations are bugs -> assert, Error, DbC, etc.

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

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 4:10 PM, Walter Bright wrote:

On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a 
straight up bug (the fact that you can just add the declaration and it 
works is pretty good proof).


It's in core.stdc.stdlib



Since it's an intrinsic (as confirmed by you), maybe we can just drop 
the version conditions? The compiler will always generate it, regardless 
of C lib, right? I'll do the PR if you agree (just want to make sure I 
understand your statements about it).


-Steve

Re: Automatic invariant generation

[ketmar via Digitalmars-d]

Steven Schveighoffer wrote:


On 7/7/17 2:27 PM, ketmar wrote:

ketmar wrote:

yeah, this is annoying. while checking for "null this" in *class* 
method may look hacky
tbh, i see nothing wrong in checking for "null this" even in class 
methods, but this is a completely different story.


In *final* methods maybe. Virtual methods are going to crash anyway 
before they get to that point.


i meant "in manual checking", i.e. "i think that compiler-inserted `assert` 
is not necessary at all". sorry for writing indecipherable engrish. ;-)

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

[Mike Wey via Digitalmars-d-announce]

On 07-07-17 22:10, Walter Bright wrote:

On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a 
straight up bug (the fact that you can just add the declaration and it 
works is pretty good proof).


It's in core.stdc.stdlib


Only for version DigitalMars and GNU.

--
Mike Wey

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

[Walter Bright via Digitalmars-d-announce]

On 7/7/2017 12:38 PM, Steven Schveighoffer wrote:
Which would mean that the lack of alloca prototype on Windows is a straight up 
bug (the fact that you can just add the declaration and it works is pretty good 
proof).


It's in core.stdc.stdlib

Re: Automatic invariant generation

[Steven Schveighoffer via Digitalmars-d]

On 7/7/17 2:27 PM, ketmar wrote:

ketmar wrote:

yeah, this is annoying. while checking for "null this" in *class* 
method may look hacky


tbh, i see nothing wrong in checking for "null this" even in class 
methods, but this is a completely different story.


In *final* methods maybe. Virtual methods are going to crash anyway 
before they get to that point.


e.g.:

class C
{
void foo() {}
final void bar() {}
}
void main()
{
C c;
version(segfault) c.foo();
version(asserts) c.bar();
}

using -vcg-ast (BTW, I really like this feature!) shows that the assert 
is still put inside foo, even though it will never trigger!


In older versions of dmd, both segfault, I think maybe because the 
virtual invariant is attempted before calling either.


-Steve

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

[Walter Bright via Digitalmars-d-announce]

On 7/7/2017 12:36 PM, Steven Schveighoffer wrote:
I thought alloca was an intrinsic? Which means that the compiler generates 
inline code to add to the stack.


I would think it has to do this, since actually calling a function would 
generate a new stack frame.


Yes and yes.

Application settings

[FoxyBrown via Digitalmars-d-learn]

What's the "best" way to do this? I want something I can simply 
load at startup in a convenient and easy way then save when 
necessary(possibly be efficient at it, but probably doesn't 
matter).


Simply json an array and save and load it, or is there a better 
way?


Ideally, I'd like to store the settings as part of the binary to 
keep everything together but that poses a few issues I think.

Re: Application settings

[Cym13 via Digitalmars-d-learn]

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
What's the "best" way to do this? I want something I can simply 
load at startup in a convenient and easy way then save when 
necessary(possibly be efficient at it, but probably doesn't 
matter).


Simply json an array and save and load it, or is there a better 
way?


Ideally, I'd like to store the settings as part of the binary 
to keep everything together but that poses a few issues I think.


I think you're better off with a simple file in a format like 
JSON or INI yeah. Simpler is better.


I don't see any easy way to save the configuration in the binary 
and would find it more troublesome than anything as an user as 
having the configuration appart means I can easily compare it 
between computers and track its changes etc.


I don't think you need to worry about performances, after all 
it's only loaded once and the config would have to be *really* 
big for it to have a noticable loading time.

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

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 3:36 PM, Steven Schveighoffer wrote:


I thought alloca was an intrinsic? Which means that the compiler 
generates inline code to add to the stack.


Which would mean that the lack of alloca prototype on Windows is a 
straight up bug (the fact that you can just add the declaration and it 
works is pretty good proof).


-Steve

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

[Steven Schveighoffer via Digitalmars-d-announce]

On 7/7/17 8:59 AM, Mike Parker wrote:
This is my latest post in the GC series. I had promised the next one 
would look at non-GC allocation strategies, but as it got longer and 
longer I decided to break it up into two parts. This part covers stack 
allocations. The next one will deal with non-GC heap allocations.


If my luck holds out, we're about to see a flurry of guest posts and 
collaborations over the next few weeks. If that pans out, I expect to 
publish the part two in mid-late August.


The blog:
https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/

Reddit:
https://www.reddit.com/r/programming/comments/6ltfwx/go_your_own_way_part_one_of_two_on_nongc/ 



I thought alloca was an intrinsic? Which means that the compiler 
generates inline code to add to the stack.


I would think it has to do this, since actually calling a function would 
generate a new stack frame.


-Steve

Re: Vibe.d - very low performance

[FoxyBrown via Digitalmars-d]

On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote:

Am 06.07.2017 um 09:27 schrieb Marek:

https://www.techempower.com/benchmarks/#section=data-r14=ph=plaintext


C++, Java and Go frameworks have very high performance. Vibe.d 
is supposed to have similar performance, but in fact vibe.d 
performance is very low. Why?


This is a scalability issue, which should hopefully be fixed 
with 0.8.0. I'll open a PR once that is out. Basically with the 
version that was used in the last benchmark round, it didn't 
scale at all, and they use a server with many cores (40 + 
hyperthreading).


So you are saying that will solve the nearly 200x factor from the 
top? At least get it in the top 20?

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

   Keywords||symdeb

--

Re: Vibe.d - very low performance

[Jacob Carlborg via Digitalmars-d]

On 2017-07-07 20:22, Marek wrote:


What do you mean by 'scalability'? Raw tornado or bottle frameworks have
much better results than vibe.d. Python and Ruby have GIL so they can't
use threads in their standard implementations. They have much better
results anyway.


I think that vibe.d didn't take full advantage of multi core, even when 
enabling threading support. Ruby, or rather Rails, applications are 
usually run using multiple processes, which allows to scale on a multi 
core CPU. You can do the same with vibe.d as well.


--
/Jacob Carlborg

Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

[ag0aep6g via Digitalmars-d-learn]

On 07/07/2017 08:29 PM, alex_ca wrote:
I'm having trouble understanding why in some cases a double value will 
be rounded up and other times down, for the same code. Here's a snippet 
with code I tried to debug:


   int getNumberOfStitchesForRowLength(double rowLength)
   {
 writeln("input ", rowLength, " ", currentGauge.stitch_gauge, " ", 
currentGauge.gauge_length);


 writeln("stitches: ", (rowLength * currentGauge.stitch_gauge) / 
currentGauge.gauge_length,  " -> " , ((rowLength * 
currentGauge.stitch_gauge) / currentGauge.gauge_length).roundTo!int);


 double end = 2.5;
 double start = 0;
 writeln("I expect: ", ((abs(end-start)*10)/10).roundTo!int);

 return ((rowLength * currentGauge.stitch_gauge) / 
currentGauge.gauge_length).roundTo!int;


   }

And here's some output from that:
input 2.5 10 10
stitches: 2.5 -> 2
I expect: 3

OR, similarly, I get

input 3.5 10 10
stitches: 3.5 -> 3
I expect: 4

However, it works as I would expect for one value:

input 1.5 10 10
stitches: 1.5 -> 2
I expect: 2

I would appreciate some ideas for why I see this seeming inconsistency. 
Or if someone can share how I can further debug this.


Works for me when I plug in the exact values:


import std.stdio;
import std.math: abs;
import std.conv: roundTo;
import std.math;

struct Gauge
{
double stitch_gauge;
double gauge_length;
}

Gauge currentGauge = Gauge(10, 10);

int getNumberOfStitchesForRowLength(double rowLength)
{
writeln("input ", rowLength, " ", currentGauge.stitch_gauge, " ",
currentGauge.gauge_length);

writeln("stitches: ",
(rowLength * currentGauge.stitch_gauge) / 
currentGauge.gauge_length,

" -> " ,
((rowLength * currentGauge.stitch_gauge) /
currentGauge.gauge_length).roundTo!int);

return ((rowLength * currentGauge.stitch_gauge) / 
currentGauge.gauge_length).roundTo!int;

}

void main()
{
foreach (x; [1.5, 2.5, 3.5])
{
getNumberOfStitchesForRowLength(x);
}
}


Prints:


input 1.5 10 10
stitches: 1.5 -> 2
input 2.5 10 10
stitches: 2.5 -> 3
input 3.5 10 10
stitches: 3.5 -> 4


As expected, right?

Could it be that the inputs aren't exactly the numbers you think they 
are? For example, when you change one the 10s to 9.999, it still 
prints as "10", but the results are different.

Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

[Ali Çehreli via Digitalmars-d-learn]

On 07/07/2017 11:29 AM, alex_ca wrote:

> input 2.5 10 10
> stitches: 2.5 -> 2
> I expect: 3

That's because what is printed as 2.5 is actually a little less than 
that. (Try printing with a format string like "%.20f".)


The common way of dealing with this issue is to add 0.5 before the 
conversion:


import std.stdio;
import std.conv;

void main() {
for (double d = 1; d < 2; d += 0.1) {
writefln("%s (%.20f): %s", d, d, (d + 0.5).to!int);
}
}

1 (1.): 1
1.1 (1.10008882): 1
1.2 (1.20017764): 1
1.3 (1.30026645): 1
1.4 (1.40035527): 1
1.5 (1.50044409): 2
1.6 (1.60053291): 2
1.7 (1.70062172): 2
1.8 (1.80071054): 2
1.9 (1.90079936): 2

Ali

[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

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

https://github.com/dlang/dlang.org/commit/b0a06c7deab4b8093d6e1fe7f592001d60a3e7c1
Fix issue 13153 - Add a version chooser to DDoc pages

--

Re: Checked vs unchecked exceptions

[Marco Leise via Digitalmars-d]

Am Thu, 06 Jul 2017 13:16:23 +
schrieb Moritz Maxeiner :

> On Thursday, 6 July 2017 at 11:01:26 UTC, Marco Leise wrote:
> > Am Thu, 06 Jul 2017 01:31:44 +
> > schrieb Moritz Maxeiner :
> >  
> >> But to be clear (and the title and description of any DIP
> >> addressing this should reflect this):
> >> These are not checked exceptions, because checked exceptions
> >> would require bar to declare its exception set manually.  
> >
> > Yep, absolutely clear. Just like "auto a = 1" does not declare
> > a variable as we all know declarations start with a type.  
> 
> Red herring.
> […]
> 
> ---
> void foo() throws AExp throws BExc { ... }
> void bar1() { foo(); } // Checked exceptions require this to 
> result in a compilation error
> void bar2() throws AExc throws BExc { foo(); } // this must be 
> used for checked exceptions
> ---

You are right, it was a red herring. The code example makes it
very obvious that inference means letting the exceptions slip
through unchecked and out of main() in the wildest case.

> Invalid premise. The definition of checked exceptions is de facto 
> fixed by Java [1], because it not only coined the term but 
> remains the only major PL to use them.

That's right, but still one can distill general ideas and
leave implementations details aside. Pretty much like the
Platonic Ideal. Then you look at what the complaints are with
the current implementation and see if you can satisfy all
sides.

I don't know if this is any good beyond an example of a
different implementation of checked exceptions, but here is
one option against the "every function in the call chain
accumulates more and more 'throws' declarations":

  /**
   * Throws:
   *   ZeroException when i is 0
   *   NonZeroException when i is not 0
   */
  void foo(int i) {
if (i == 0) throw new ZeroException();
throw new NonZeroException();
  }

  void bar(int i) @check_exceptions {
foo(i);  // Error: The following exceptions are not
  handled:
 // ZeroException thrown from foo() when i is 0
 // NonZeroException thrown from foo() when i is not 0
  }

I.e. everything stays the same until a programmer needs a
verification of what (s)he should/could handle right away,
what needs to be wrapped and what can be passed further up the
call chain. That's close to impossible now in deeply nested
code.

Resource unavailability prone to race conditions can often be
handled by asking the user to fix the issue and continue for
example (including network, disk space, RAM, video encoding
hardware slots, exclusive microphone use).

In other cases an exception is only thrown when an incorrect
argument is passed. Knowing (statically) that you pass only
good values you can catch the exception and turn it into an
assert instead of passing it up the call chain, potentially
allowing the caller to be nothrow.
-- 
Marco

[Issue 4354] Phobos should expose per-thread errno

[via Digitalmars-d-bugs]

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

--- Comment #4 from Andrei Alexandrescu  ---
This is a reproducible problem on Windows (at least with wine). We use a C
small file in druntime (src/core/stdc/errno.c) to make sure we use the C macro.
Far as I can tell the same technique is used across Windows and Posix, which
indicates the problem is with dmc's stdlib.

--

Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

[alex_ca via Digitalmars-d-learn]

Hi,

I'm having trouble understanding why in some cases a double value 
will be rounded up and other times down, for the same code. 
Here's a snippet with code I tried to debug:


  int getNumberOfStitchesForRowLength(double rowLength)
  {
writeln("input ", rowLength, " ", currentGauge.stitch_gauge, 
" ", currentGauge.gauge_length);


writeln("stitches: ", (rowLength * currentGauge.stitch_gauge) 
/ currentGauge.gauge_length,  " -> " , ((rowLength * 
currentGauge.stitch_gauge) / 
currentGauge.gauge_length).roundTo!int);


double end = 2.5;
double start = 0;
writeln("I expect: ", ((abs(end-start)*10)/10).roundTo!int);

return ((rowLength * currentGauge.stitch_gauge) / 
currentGauge.gauge_length).roundTo!int;


  }

And here's some output from that:
input 2.5 10 10
stitches: 2.5 -> 2
I expect: 3

OR, similarly, I get

input 3.5 10 10
stitches: 3.5 -> 3
I expect: 4

However, it works as I would expect for one value:

input 1.5 10 10
stitches: 1.5 -> 2
I expect: 2

I would appreciate some ideas for why I see this seeming 
inconsistency. Or if someone can share how I can further debug 
this.


Thanks!

I'm using DMD32 D Compiler v2.074.1 on Windows

Re: Automatic invariant generation

[ketmar via Digitalmars-d]

ketmar wrote:

yeah, this is annoying. while checking for "null this" in *class* method 
may look hacky


tbh, i see nothing wrong in checking for "null this" even in class methods, 
but this is a completely different story.

Re: Automatic invariant generation

[ketmar via Digitalmars-d]

Steven Schveighoffer wrote:

Hm... it doesn't look like an invariant, it just looks like an inserted 
assert inside every function.


An incorrect assert, IMO:

struct Foo
{
 int x;
 void foo() {}
}

void main()
{
Foo *foo;
foo.foo(); // shouldn't assert, wouldn't crash anyway.
}


yeah, this is annoying. while checking for "null this" in *class* method 
may look hacky, i see nothing wrong in "null this" for struct method. tbh, 
i patched that assert (the whole invariant thingy, actually) away long time 
ago, and only remembered about it recently, when my code spit that error in 
vanilla. real PITA, 'cause adding useless checks for "if this struct 
pointer isn't null, then assign what struct method will assign on null, and 
don't forget to sync it when i'll change method, and no, you cannot assert 
in ternaly without deprecated comma, and... no, that code won't be 
converted to 'normal D'."

Re: Vibe.d - very low performance

[Marek via Digitalmars-d]

On Thursday, 6 July 2017 at 10:57:31 UTC, Sönke Ludwig wrote:
This is a scalability issue, which should hopefully be fixed 
with 0.8.0. I'll open a PR once that is out. Basically with the 
version that was used in the last benchmark round, it didn't 
scale at all, and they use a server with many cores (40 + 
hyperthreading).


What do you mean by 'scalability'? Raw tornado or bottle 
frameworks have much better results than vibe.d. Python and Ruby 
have GIL so they can't use threads in their standard 
implementations. They have much better results anyway.

Re: Address of a lambda

[Ali Çehreli via Digitalmars-d-learn]

On 07/07/2017 10:52 AM, Ali Çehreli wrote:
> a solution with the addition of the
> keyword 'delegate':

As ag0aep6g explained, the 'delegate' keyword was not necessary there. A 
case where it's needed is when defining a variable. The following code 
compiles if 'delegate' keyword is present:


void foo(int delegate (int)) {
}

void main() {
// 'delegate' keyword needed to compile:
auto f = delegate (int i) => i * 2;
foo(f);
}

Ali

[Issue 17526] Add a set method for AA

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
BTW, the performance use case of the proposed set method (which I called
getOrAdd in my hashmap implementation):

struct S { int i, j, k, l, m; /* etc. */ }
S[int] aa;

// The goal is to increment aa[x].k
// If aa[x] doesn't exist, initialize it with S.init
// Currently, you have to do this:

if (auto p = x in aa)
(*p).k++;
else
{
S s;
s.k = 1;
aa[x] = s;  // Wasteful - double lookup
}

--

[Issue 17619] New: [REG2.072] Wrong debug line information with single line loops

[via Digitalmars-d-bugs]

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

  Issue ID: 17619
   Summary: [REG2.072] Wrong debug line information with single
line loops
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: m...@krej.cz

void main()
{
foreach (i; 0 .. 3)
i++;

int bad; // shown during loop
}

Breakpoint 1, D main () at loop3.d:3
3   foreach (i; 0 .. 3)
(gdb) n
4   i++;
(gdb)
6   int bad; // shown during loop
(gdb)
4   i++;
(gdb)
6   int bad; // shown during loop
(gdb)
4   i++;
(gdb)
6   int bad; // shown during loop
(gdb)
6   int bad; // shown during loop
(gdb)
7   }

When compiled with older DMD:

Breakpoint 1, D main () at loop3.d:3
3   foreach (i; 0 .. 3)
(gdb) n
4   i++;
(gdb)
3   foreach (i; 0 .. 3)
(gdb)
4   i++;
(gdb)
3   foreach (i; 0 .. 3)
(gdb)
4   i++;
(gdb)
3   foreach (i; 0 .. 3)
(gdb)
6   int bad; // shown during loop
(gdb)
7   }

Introduced by https://github.com/dlang/dmd/pull/2867

--

[Issue 17526] Add a set method for AA

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
(In reply to hsteoh from comment #3)
> What about a const overload to opIndexAssign that lets you assign to a new
> key, but aborts if the key already exists?

I'm not sure; I think the semantics would be a bit surprising. E.g. generally
if is(typeof(aa[key]=value)) is true, you'd expect it to work at runtime as
well (for POD types, at least).

> I'm a little hesitant about
> adding a whole new method to set a key in an AA.

I think it would be useful, but I agree it's a bigger addition that might use
more discussion. Not enough for a DIP, but it could be discussed in the pull
request if one were to make one.

I know Martin wants to give a templated AA implementation another go soon:
https://wiki.dlang.org/Vision/2017H2_draft

--

Re: Can we get rid of non-raw write?

[Nick Sabalausky via Digitalmars-d]

Vetoed after several years of nothing:
https://issues.dlang.org/show_bug.cgi?id=9776#c7

I'm getting really fucking tired of D making up excuses to throw 
"do the right thing by default" straight into the gutter. D 
steering didn't used to be this way, and that was exactly what 
make D into something worthwhile in the first place. Now we're 
just diving head-first into C++-management (minus the committes).

Re: Address of a lambda

[ag0aep6g via Digitalmars-d-learn]

On 07/07/2017 07:33 PM, FoxyBrown wrote:
In gtk, we routinly have to use delegates for callbacks. But the methods 
that accept these delegates want the address of the delegate,


I don't think that's true. As far as I can tell, this is the signature 
of addOnDelete [1]:



gulong addOnDelete(bool delegate(Event, Widget) dlg, ConnectFlags 
connectFlags=cast(ConnectFlags)0)



`dlg` is just a delegate, not a pointer to a delegate.

this 
prevents us from being able to pass a lambda in directly, but there 
really is not reason why we shouldn't be able to do this?


Fine:
void main()
{
bool windowDelete(Event event, Widget widget) {Main.quit(); return 
false; }

MainWindow.addOnDelete();
}


Here you're "taking the address" of a method. The result is a delegate, 
not a pointer to a delegate. The delegate is the address/pointer (plus 
another pointer to some related context).



Invalid:

void main()
{
MainWindow.addOnDelete(&((Event event, Widget widget) {Main.quit(); 
return false; }));

}


Remove the `&` operator and it should work. The function literal [2] 
already makes a delegate.


and yet, the only difference is a copy and paste(i.e., a rewrite rule, 
at most). Surely the compiler can figure out that we can take such an 
address because anything that actually exists must have an address 
somewhere.


Stuff can exist in registers only. In a function call `f(42)`, 42 likely 
goes directly into a register, not into memory.


Seems like an arbitrary blocker? Even if it saves us from 
some obscure problems, it should work in most cases and be allowed when 
used in those cases.


What's even stranger is that the function windowDelete must be declared 
in some type of object, such as another function, so it is actually a 
delegate, if one has it in the module root then it is a normal function 
and cannot be passed to addOnDelete, even though, again, there is very 
little difference.


Yeah, that's an interesting oddity. The problem is that the parameters 
of a `void delegate(int foo, int bar)` are possibly passed differently 
from those of a `void function(int foo, int bar)`.


Related thread:

http://forum.dlang.org/post/ofc0lj$2u4h$1...@digitalmars.com

[...]
I do know the difference between a delegate and a function, and I 
suppose addOnDelete should be defined to take a function instead?


If anything, it should accept both. Not a function instead of a delegate.

But 
how can we create a "delegate function" similar to the nested delegate 
in the first case that works so that we can pass them as delegates?


http://dlang.org/phobos/std_functional.html#toDelegate


[1] 
https://github.com/gtkd-developers/GtkD/blob/5c2ee83aae7425b683709593c5fd44a7ab1db067/generated/gtkd/gtk/Widget.d#L6793

[2] https://dlang.org/spec/expression.html#function_literals

Re: Address of a lambda

[FoxyBrown via Digitalmars-d-learn]

On Friday, 7 July 2017 at 17:52:25 UTC, Ali Çehreli wrote:

On 07/07/2017 10:33 AM, FoxyBrown wrote:
> [...]
the methods
> [...]

I'm not a user but I don't think it's right. According to the 
following, it takes a delegate:


[...]


Thanks, I guess one doesn't need to pass the address(I copied the 
code from somewhere and it was so I made an assumption).


One doesn't need the delegate keyword or &, but the question then 
is why does & work? Seems to have done not affect the behavior.

Re: Address of a lambda

[Ali Çehreli via Digitalmars-d-learn]

On 07/07/2017 10:33 AM, FoxyBrown wrote:
> In gtk, we routinly have to use delegates for callbacks. But the methods
> that accept these delegates want the address of the delegate,

I'm not a user but I don't think it's right. According to the following, 
it takes a delegate:



https://github.com/gtkd-developers/GtkD/blob/42ef854f7cd975519926900fe326e220410c028a/demos/gtkD/DemoMultiCellRenderer/DemoMultiCellRenderer.d#L124

wnd.addOnDelete( delegate bool (Event event, Widget widget) {
widget.destroy();
Main.quit();
return false;
});

> this
> prevents us from being able to pass a lambda in directly, but there
> really is not reason why we shouldn't be able to do this?

I think that's because the lambda is a 'function' if can be for 
efficiency reasons.


> Invalid:
>
> void main()
> {
> MainWindow.addOnDelete(&((Event event, Widget widget) {Main.quit();
> return false; }));
> }

It makes it very difficult to help if there is no code that demonstrates 
the problem. Here is my attempt and a solution with the addition of the 
keyword 'delegate':


alias Event = int;
alias Widget = int;

struct MainWindow {
static void quit() {
}

static void addOnDelete(bool delegate(Event, Widget)) {
}
}

MainWindow Main;

void main() {
// ADDED 'delegate':
MainWindow.addOnDelete(delegate (Event event, Widget widget) {
Main.quit(); return false;
});
}

So, there is no need to take the address of a lambda. It's already 
either a 'function' or a delegate.


> I
> suppose addOnDelete should be defined to take a function instead?

That would limit the users if they wanted to maintain state for the 
function.


> But
> how can we create a "delegate function" similar to the nested delegate
> in the first case that works so that we can pass them as delegates?

Being explicit like above is one way. There is also toDelegate:

  https://dlang.org/phobos/std_functional.html#toDelegate

> And aside, shouldn't all functions really be delegates?

Not in a system language like D that tries to avoid unnecessary cost. :)

Ali

Re: Address of a lambda

[NoIdeaForaGoodPseudo via Digitalmars-d-learn]

On Friday, 7 July 2017 at 17:33:33 UTC, FoxyBrown wrote:
In gtk, we routinly have to use delegates for callbacks. But 
the methods that accept these delegates want the address of the 
delegate, this prevents us from being able to pass a lambda in 
directly, but there really is not reason why we shouldn't be 
able to do this?


[...]


Lambdas are for very localized and small delegates, typically in 
algorithms and functional programming. Delegates assigned to 
events in GUI toolkits are often meant to be reusable, e.g 
assignable to different listeners and also must be known (have 
addresses) to be usable in GUI designers. That's not what lambda 
are made for.

[Issue 12949] Project compilation time increased by 64% for last half year

[via Digitalmars-d-bugs]

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

--- Comment #5 from Vladimir Panteleev  ---
(In reply to Rainer Schuetze from comment #3)
> An error occured while loading the graph data (data/data.json)
> parsererror: SyntaxError: Unexpected end of JSON input

BTW, that error manifests because the amount of data has grown so large that
browsers now choke on it. I need to seriously refactor the front end to make it
stream in data as needed from the server instead of loading it all at once.

--

[Issue 12949] Project compilation time increased by 64% for last half year

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Rainer Schuetze from comment #3)
> What about "Is D slim yet?" http://digger.k3.1azy.net/trend/ produces an
> error for me:
> 
> An error occured while loading the graph data (data/data.json)
> parsererror: SyntaxError: Unexpected end of JSON input

Yep, that was my effort on improving the situation with regards to the general
problem.

That project has been superseded by a CI system which integrated it, however I
abandoned work on the CI system after being told custom CI systems are a bad
idea.

--

[Issue 12949] Project compilation time increased by 64% for last half year

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
What about "Is D slim yet?" http://digger.k3.1azy.net/trend/ produces an error
for me:

An error occured while loading the graph data (data/data.json)
parsererror: SyntaxError: Unexpected end of JSON input

--

[Issue 9776] Make raw write mode the default

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Vladimir Panteleev  ---
Whether you agree or disagree, everything here works "as designed", i.e. "do
what C does".

As explained, changing the default behaviour of File.open would be a breaking
change and is not going to happen.

--

[Issue 12949] Project compilation time increased by 64% for last half year

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Vladimir Panteleev  ---
Unfortunately this issue is not actionable.

Tracking compilation performance is something we want to do in general, but it
is a very broad subject.

Tracking a regression in build time of a specific project may be more directly
actionable (or at least possible to investigate), but no test case has been
provided.

I'll close this as it was filed 3 years ago, and there doesn't seem to be much
utility in leaving this open today.

--

[Issue 7623] Allow aliasing of symbols of an aliased subtype

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
Pretty sure this can't work for the same reason `alias foo.isOne isTwo` doesn't
work - you can't alias an expression.

--

Address of a lambda

[FoxyBrown via Digitalmars-d-learn]

In gtk, we routinly have to use delegates for callbacks. But the 
methods that accept these delegates want the address of the 
delegate, this prevents us from being able to pass a lambda in 
directly, but there really is not reason why we shouldn't be able 
to do this?


Fine:
void main()
{
bool windowDelete(Event event, Widget widget) {	Main.quit(); 
return false; }

MainWindow.addOnDelete();
}

Invalid:

void main()
{
MainWindow.addOnDelete(&((Event event, Widget widget) 
{	Main.quit(); return false; }));

}


and yet, the only difference is a copy and paste(i.e., a rewrite 
rule, at most). Surely the compiler can figure out that we can 
take such an address because anything that actually exists must 
have an address somewhere. Seems like an arbitrary blocker? Even 
if it saves us from some obscure problems, it should work in most 
cases and be allowed when used in those cases.


What's even stranger is that the function windowDelete must be 
declared in some type of object, such as another function, so it 
is actually a delegate, if one has it in the module root then it 
is a normal function and cannot be passed to addOnDelete, even 
though, again, there is very little difference.


Invalid:

bool windowDelete(Event event, Widget widget) {	Main.quit(); 
return false; }


void main()
{
MainWindow.addOnDelete();
}



I do know the difference between a delegate and a function, and I 
suppose addOnDelete should be defined to take a function instead? 
But how can we create a "delegate function" similar to the nested 
delegate in the first case that works so that we can pass them as 
delegates?


And aside, shouldn't all functions really be delegates? Having a 
closure of the outer scope still holds at the module root 
level(the scope is the module root). While it's an extra argument 
to pass, it could simplify live a bit. The corner cases could be 
handled by explicitly forcing it to be a function.

[Issue 12995] Include UDA in JSON output

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||json

--

[Issue 16531] Protected members not accessible in delegate bodies

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Hardware|x86_64  |All
 OS|Windows |All

--

[Issue 13605] Add ability to `version` a module declaration

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #10 from Vladimir Panteleev  ---
No, no, no, no, no.

Module names must match file names. The compiler allowed them to not match
mainly for historical reasons (compatibility with C build systems). Nowadays
build / instrumentation / etc. tools all make this assumption. Perpetuating
this anti-feature is only harming the D ecosystem by putting unreasonable
burden on tool developers.

The task as described in the original issue description is canonically solved
with a public import.

--

[Issue 16499] Misleading error message for 'in' operator with wrong argument

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc

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

--

[Issue 3905] Wrong error message with wrong opBinary("in")

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #7 from Vladimir Panteleev  ---
The error message is now:

test.d(7): Error: incompatible types for ((3) in (Group(1, 2))): 'int' and
'Group'

Fixed by https://github.com/dlang/dmd/pull/6140

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

--

Re: GDB behaves strange with DMD

[Martin Krejcirik via Digitalmars-d-debugger]

Dne 4. 7. 2017 v 13:46 Gorthad napsal(a):

As you see, GDB seems to have wrong info about line numbers.


This is acually a regression since 2.072. I'll file a bug report.

--
mk

[Issue 17618] parse booktables manually to check whether symbols haven't been mentioned

[via Digitalmars-d-bugs]

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

--- Comment #1 from Seb  ---
See also: https://github.com/dlang-community/D-Scanner/issues/494

--

[Issue 17618] New: parse booktables manually to check whether symbols haven't been mentioned

[via Digitalmars-d-bugs]

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

  Issue ID: 17618
   Summary: parse booktables manually to check whether symbols
haven't been mentioned
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Grouped booktables are awesome - they look very nice and give the reader and
quick overview (except for std.traits).

However, it repeatedly happened that when new symbols get added, these
booktables aren't updated.

Two ideas:

For all modules with a booktable

1) Parse the public symbols and check whether all have been mentioned in the
module comment (a simple `find` could do)
2) Use a Group: xxx key in the function comment header and build the booktable
as postprocessing of Ddoc.

Probably doing (1) as a DScanner check is the easiest.

https://github.com/dlang/phobos/pull/5570/files

--

[Issue 7179] Hash algorithm vulnerable to algorithmic complexity attacks

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Priority|P2  |P1
   Severity|normal  |critical

--

[Issue 9137] A function that equals to "out of scope" action for manual lifetime management

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Vladimir Panteleev  ---
The PR was rejected, closing.

https://github.com/dlang/phobos/pull/929#issuecomment-11167033

--

[Issue 9139] `destroy` is dangerous and inconsistent

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Vladimir Panteleev  ---
(In reply to Denis Shelomovskii from comment #0)
> It also behaves fine in some cases. But it
> will do unpredictable things in other cases.

This bug report is close to useless due to vague language like that.

As it was filed close to 5 years ago, and Object.destroy has received updates
since then, I am going to close this, but please reopen if you think this is
still an issue and can present concrete examples of problematic code.

--

[Issue 13397] allow postfix function attributes like 'safe', 'system' and so on without '@'

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #14 from Vladimir Panteleev  ---
Such language changes need to be proposed through the DIP process:

https://github.com/dlang/DIPs

Bugzilla is not the correct place for language enhancements. Without a DIP,
this patch will not be accepted, so there's no point in keeping this issue
open.

--

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #2 from RazvanN  ---
Actually, I think NotComparable is the best pick.

--

[Issue 17308] [TEST/PROCESS] Beta releases should not be built with -release

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
> Beta releases should not be built with -release 

Err, no, beta releases should be as close as possible to the final release.
I've lost count of the number of times I shipped a broken build of some project
only because the bug was not reproducible in the debug version. So, I'm pretty
sure having different build flags for betas and releases a bad idea.

Nightly builds are a different story and I think could be built with
assertions.

I'm closing this as WONTFIX as I'm pretty sure the issue as stated would be a
bad idea, but please reopen if you can argument the opposite or can suggest
some other actionable way to improve the situation.

--

[Issue 15005] Coverage files start with a dash character when using full pathname for source files with -cov

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--