Re: proposed @noreturn attribute

On 7/8/2017 9:32 PM, Meta wrote: On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote: On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote: (D already has a `void` type, so can't use Haskell's word.) Just so we are all on the same page, from a type-theory perspective void is a unit

Re: proposed @noreturn attribute

On 7/8/2017 9:23 PM, Meta wrote: On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote: (D already has a `void` type, so can't use Haskell's word.) Just so we are all on the same page, from a type-theory perspective void is a unit type (it has 1 value), not an uninhabited type (it has

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

https://issues.dlang.org/show_bug.cgi?id=17596 --- Comment #5 from Cy Schubert --- Thanks. I'll develop a patch (will take some time -- I have a number of projects on the fly at the moment). The patch will will work for FreeBSD 12 after r318736 but break all FreeBSD releases

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

https://issues.dlang.org/show_bug.cgi?id=17625 Ketmar Dark changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=17625 Issue ID: 17625 Summary: Confusing error message for private functions in different modules Product: D Version: D2 Hardware: All OS: All Status: NEW

Re: proposed @noreturn attribute

On 07/08/2017 05:03 PM, Vladimir Panteleev wrote: On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote: @disable @property None init(); You meant static here I guess. The compiler detects (without having anything hardwired about the particular type "None") that the type

Re: proposed @noreturn attribute

On 07/08/2017 10:25 PM, Walter Bright wrote: On 7/8/2017 7:01 PM, sarn wrote: On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote: We have types that cannot be named (Voldemort types), types that have no type (void), I suppose that types that cannot exist will fill out the edge cases

Re: proposed @noreturn attribute

On Sunday, 9 July 2017 at 04:23:15 UTC, Meta wrote: On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote: (D already has a `void` type, so can't use Haskell's word.) Just so we are all on the same page, from a type-theory perspective void is a unit type (it has 1 value), not an

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

https://issues.dlang.org/show_bug.cgi?id=16650 --- Comment #4 from Vladimir Panteleev --- It's easy enough to test! $ cat test.d pragma(mangle, "CeciNestPasUnS") struct S { } extern(C++) void fun(S* s); pragma(msg, fun.mangleof); $ dmd -o- test.d _Z3funP1S

Re: proposed @noreturn attribute

On Sunday, 9 July 2017 at 02:25:50 UTC, Walter Bright wrote: (D already has a `void` type, so can't use Haskell's word.) Just so we are all on the same page, from a type-theory perspective void is a unit type (it has 1 value), not an uninhabited type (it has no values, i.e. Haskell's _|_

Re: CTFE output is kind of weired

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

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

https://issues.dlang.org/show_bug.cgi?id=17624 Issue ID: 17624 Summary: typo in Fields documentation section of https://dlang.org/library/object/exception.html Product: D Version: D2 Hardware: All OS: All

Re: proposed @noreturn attribute

On Sun, Jul 09, 2017 at 02:01:26AM +, sarn via Digitalmars-d wrote: > On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote: > > We have types that cannot be named (Voldemort types), types that > > have no type (void), I suppose that types that cannot exist will > > fill out the edge

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

Type info is always generated for struct that contain structs that have an alias this. This was apparently done because of https://issues.dlang.org/show_bug.cgi?id=14948 and "fixed" in https://github.com/dlang/dmd/pull/5001 , see also

Re: rdmd vs dmd WRT static constructors

On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote: On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote: To include stat1.d and stat2.d in the compilation, you'll either have to import them in statmain.d or use the --extra-file command line switch: rdmd --extra-file=stat1.d

Re: rdmd vs dmd WRT static constructors

On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote: $ rdmd statmain.d stat1.d stat2.d // outputs nothing... Bug or intended behaviour? rdmd takes the first D file you give it, follows its import tree, and compiles all the modules found there. Anything on the command line after

rdmd vs dmd WRT static constructors

RDMD does not behave the same as DMD WRT static constructors. The following example, extracted form Mike Parker's "Learning D", does not produce the same result: // stat1.d module stat1; import std.stdio; static this() { writeln("stat1 constructor"); } // stat2.d module stat2; import

Re: proposed @noreturn attribute

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

Re: proposed @noreturn attribute

On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote: We have types that cannot be named (Voldemort types), types that have no type (void), I suppose that types that cannot exist will fill out the edge cases of the menagerie. I assume there is a standard jargon for this - does anyone

Re: proposed @noreturn attribute

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

Re: Beta 2.075.0-b2

On Saturday, 8 July 2017 at 23:53:57 UTC, Martin Nowak wrote: On Friday, 7 July 2017 at 09:27:15 UTC, Paolo Invernizzi wrote: /Paolo We've recently changed the versioning of development builds and when we bump the hardcoded VERSION file https://github.com/dlang/dmd/pull/6935. Looks like we

[Issue 9776] Make raw write mode the default

https://issues.dlang.org/show_bug.cgi?id=9776 --- Comment #10 from Nick Sabalausky --- As already said before, windows notepad is the *only program that doesn't handle it (which makes it very *unlike* '/' if indeed "many programs" fail to deal with properly - which

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

https://issues.dlang.org/show_bug.cgi?id=17004 Seb changed: What|Removed |Added CC||greensunn...@gmail.com ---

Re: proposed @noreturn attribute

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

[Issue 6410] Few common exceptions in std.exception

https://issues.dlang.org/show_bug.cgi?id=6410 --- Comment #6 from Jonathan M Davis --- (In reply to greenify from comment #5) > FYI there will be HttpStatusException soon: > https://github.com/dlang/phobos/pull/5551 Yeah, but it's not generic. It's derived from

Re: Beta 2.075.0-b2

On Friday, 7 July 2017 at 09:27:15 UTC, Paolo Invernizzi wrote: /Paolo We've recently changed the versioning of development builds and when we bump the hardcoded VERSION file https://github.com/dlang/dmd/pull/6935. Looks like we need to update that file for every pre-release now to please

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote: struct None { @disable this(); @disable this(this); @disable @property None init(); } None ThisFunctionExits(); The compiler detects (without having anything hardwired about the particular type "None") that the

Re: CTFE output is kind of weired

On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d- learn wrote: > On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote: > > app.d(17):called from here: test("1234\x0a5678\x0a") > > > > I wrote the source code on windows with a source file with \r\n > > file

Re: The Nullity Of strings and Its Meaning

Just saw that my first example was wrong, it should read 1 void main () 2 { 3import std.uri; 4string a = ""; 5assert (a); 6auto s = a.decodeComponent; 7assert (s); 8 } The non-nullity was not preserved. Only the second assert

Re: The Nullity Of strings and Its Meaning

On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn wrote: > Yesterday I noticed that std.uri.decodeComponent does not > 'preserve' the > nullity of its argument: > > 1 void main () > 2 { > 3import std.uri; > 4string s = null; > 5assert (s is

Re: Current state of the Garbage Collector

Recent thread about this topic: http://forum.dlang.org/thread/ewdoqmvslcnypzyrb...@forum.dlang.org Ali

Re: proposed @noreturn attribute

On 7/8/2017 1:20 PM, H. S. Teoh via Digitalmars-d wrote: Hmmm. Just to clarify, what exactly does @noreturn include? If I have a function that calls exit(), that's @noreturn? What about a function that always throws? Or a function that calls exec()? A function that always ends in assert(0)? A

Re: CTFE output is kind of weired

On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote: app.d(17):called from here: test("1234\x0a5678\x0a") I wrote the source code on windows with a source file with \r\n file endings. But the console output has only the character X0a. In addition not the content of tmp is shown

Re: CTFE output is kind of weired

On 07/08/2017 02:29 PM, Andre Pany wrote: > I use assert(false, tmp) to see the content of variable tmp as it seems > there is no other way in CTFE. A more natural way is pragma(msg), which you can use in main in this case: string test(string s) { string tmp = s; tmp = tmp[4..$];

CTFE output is kind of weired

Hi, I use assert(false, tmp) to see the content of variable tmp as it seems there is no other way in CTFE. The output is kind of weired: app.d(6): Error: "1234\x0a5678\x0a"[4..10] app.d(17):called from here: test("1234\x0a5678\x0a") I wrote the source code on windows with a source

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 21:03:57 UTC, Vladimir Panteleev wrote: This particular one is countered by also adding a disabled destructor. Oops, never mind that - this makes the function uncallable.

Re: Application settings

I use protocol buffers (using dproto) for this, storing my settings in either text or wire format. Advantages: type-safety with fwd/backward compatibility (unlike json which requires dynamic field access, eg with dproto you get errors at compile time instead of runtime), supports comments

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote: @disable @property None init(); You meant static here I guess. The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a

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

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

Faster alternatives to std.xml

What's the fastest XML-parser on code.dlang.org? Are there any benchmarks that show performance improvements compared to std.xml?

Re: proposed @noreturn attribute

On Sat, Jul 08, 2017 at 01:20:03PM -0700, H. S. Teoh via Digitalmars-d wrote: [...] > Personally, I'm for this. It is useful for functions that constructs > then throws an exception, for example. It would be nice to be able to > call such a function from another function that returns non-void >

Re: proposed @noreturn attribute

On Sat, Jul 08, 2017 at 01:09:35PM -0700, Walter Bright via Digitalmars-d wrote: > On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote: > > None ThisFunctionExits(); > > > > The compiler detects (without having anything hardwired about the > > particular type "None") that the type None is impossible

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

https://issues.dlang.org/show_bug.cgi?id=16650 --- Comment #3 from Jacob Carlborg --- Is it possible to use pragman(mangle) on a struct? --

Re: proposed @noreturn attribute

On 7/8/2017 10:14 AM, Jack Stouffer wrote: On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote: Why should this be an attribute rather than a pragma? I agree. There's no reason I can think of as to why the no-return should be part of the ABI. Separate compilation. I.e. if one changes

Re: proposed @noreturn attribute

On 7/8/2017 5:17 AM, Andrei Alexandrescu wrote: None ThisFunctionExits(); The compiler detects (without having anything hardwired about the particular type "None") that the type None is impossible to create and copy/move from a function, and therefore decrees the function will never return.

Re: proposed @noreturn attribute

On 7/8/2017 3:52 AM, Nicholas Wilson wrote: consider that GDC and LDC already both have that attribute courtesy of their backends (@attribute("noreturn") and @llvmAttr("noreturn") respectively). One could argue that since "noreturn" changes the interface of a function, it should also change

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

https://issues.dlang.org/show_bug.cgi?id=16856 --- Comment #11 from Nemanja Boric <4bur...@gmail.com> --- https://github.com/dlang/druntime/pull/1862 --

[Issue 9776] Make raw write mode the default

https://issues.dlang.org/show_bug.cgi?id=9776 Walter Bright changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=16397 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/1f7e59980539fe0f9ba352b258e8266db6bdff01 fix test coverage - use single tests as workaround for

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

https://issues.dlang.org/show_bug.cgi?id=17623 Vladimir Panteleev changed: What|Removed |Added Keywords||spec

[Issue 17622] inline for m64 fails web APPS

https://issues.dlang.org/show_bug.cgi?id=17622 --- Comment #2 from Vladimir Panteleev --- Please provide a full self-contained test case, so that we can reproduce the bug. --

Re: proposed @noreturn attribute

On 7/8/17 1:30 PM, Stefan Koch wrote: On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote: What is the signature of a function that logs something to a file and ends in assert(0)? I do get your point. However I still doubt that this is worth a the additional language

Re: proposed @noreturn attribute

On 7/8/17 2:26 PM, John Colvin wrote: I wonder if some lessons from Haskell's "bottom" type would be relevant here. Affirmative. The nice touch of bottom (heh) is that it's convertible to anything, so you can use it in complex expressions as a wildcard. -- Andrei

Re: The Nullity Of strings and Its Meaning

On 07/08/2017 07:16 PM, kdevel wrote: The assertion in line 6 fails. This failure gave rise to a more general investigation on strings. After some research I found that one "cannot implicitly convert expression (s) of type string to bool" as in [...] Nonetheless in certain boolean contexts

Re: Application settings

On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote: On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote: On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote: On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote: [...] "best" always depends on your specific use case. I

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote: On 7/8/17 6:15 AM, Walter Bright wrote: Has anyone a better idea? Does anyone want to write a DIP for this? An attribute is fine. A more PL-minded possibility is to return a specific type: struct None { @disable

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

https://issues.dlang.org/show_bug.cgi?id=16397 --- Comment #2 from Martin Nowak --- cat > a.d << CODE module a; import b; unittest { foo!int(); } CODE cat > b.d << CODE module b; void foo(T)() { return; // line is covered } unittest { foo!int(); } CODE dmd -c -cov

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

https://issues.dlang.org/show_bug.cgi?id=16856 --- Comment #10 from Nemanja Boric <4bur...@gmail.com> --- Ok, I finally got some time to get back to this issue. There's a sigbus really running, but this is caused by GC, because the runtime asserts in the shared library finalizers, so it seems

[Issue 5077] std.algorithm.schwartzSort is slow

https://issues.dlang.org/show_bug.cgi?id=5077 safety0ff.bugz changed: What|Removed |Added CC|

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

https://issues.dlang.org/show_bug.cgi?id=16397 Martin Nowak changed: What|Removed |Added Summary|test_runner in coverage |missing coverage from

Re: The Nullity Of strings and Its Meaning

On 08.07.2017 19:16, kdevel wrote: I wonder if this distinction is meaningful Not nearly as much as it would need to be to justify the current behavior. It's mostly a historical accident. and---if not---why it is exposed to the application programmer so prominently. I don't think there

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

On 07.07.2017 16:17, Jonathan M Davis via Digitalmars-d wrote: On Friday, July 7, 2017 1:38:13 PM MDT Stefan Koch via Digitalmars-d wrote: On Friday, 7 July 2017 at 13:34:20 UTC, Steven Schveighoffer wrote: On 7/7/17 4:21 AM, Nicholas Wilson wrote: The compiler seems to inset an `assert(this

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

https://issues.dlang.org/show_bug.cgi?id=16397 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1

Re: Release fluent-asserts 0.6.0

On Sunday, 2 July 2017 at 13:34:25 UTC, Szabo Bogdan wrote: Hi, I just made a new release of fluent-asserts: http://fluentasserts.szabobogdan.com/ https://code.dlang.org/packages/fluent-asserts Since my last announcement I improved the library with: - better error messages - better

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 17:14:32 UTC, Andrei Alexandrescu wrote: What is the signature of a function that logs something to a file and ends in assert(0)? I do get your point. However I still doubt that this is worth a the additional language complexity. Usually the clue would be in

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

https://issues.dlang.org/show_bug.cgi?id=17621 Vladimir Panteleev changed: What|Removed |Added Status|NEW

Re: proposed @noreturn attribute

On 07/08/2017 01:14 PM, Jack Stouffer wrote: On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote: Why should this be an attribute rather than a pragma? I agree. There's no reason I can think of as to why the no-return should be part of the ABI. If present in the signature of the

The Nullity Of strings and Its Meaning

Yesterday I noticed that std.uri.decodeComponent does not 'preserve' the nullity of its argument: 1 void main () 2 { 3import std.uri; 4string s = null; 5assert (s is null); 6assert (s.decodeComponent); 7 } The assertion in line 6 fails. This failure gave

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 11:07:32 UTC, bachmeier wrote: Why should this be an attribute rather than a pragma? I agree. There's no reason I can think of as to why the no-return should be part of the ABI.

Re: proposed @noreturn attribute

On 07/08/2017 08:20 AM, Stefan Koch wrote: ... since it's going to be special cased by the compiler we might as well hardwire a type called none. Walter and I have repeated experience with moving compiler smarts into library artifacts. Sometimes it's arguably not the best way to go, but in

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

https://issues.dlang.org/show_bug.cgi?id=17556 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/941e2936b6c90fce0b11eada9605c231ca498e9f Fix Issue 17556 - std.json encodes non-BMP characters

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

https://issues.dlang.org/show_bug.cgi?id=5904 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b23e7a4107cc2eb3275e022cb46f7270e586ca29 Fix Issue 5904 - std.json parseString doesn't handle

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

https://issues.dlang.org/show_bug.cgi?id=17555 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/55aa34e4407cd24a29f5e271a3fa318d56acf487 Fix Issue 17555 - [REG2.070.0] Control characters in

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

https://issues.dlang.org/show_bug.cgi?id=17623 Issue ID: 17623 Summary: Unexpected failure of an assertion on empty strings Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal

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

https://issues.dlang.org/show_bug.cgi?id=17564 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/4a5d2b3b189f072e9bd0b1779a7d585e3945921b Fix issue 17564: Eliminate "static this" for

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

https://issues.dlang.org/show_bug.cgi?id=17557 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/226f8e001c256836bdcc7917443704db93f318c3 Fix Issue 17557 - std.json should not do UTF decoding

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

https://issues.dlang.org/show_bug.cgi?id=17553 --- Comment #4 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/5031ff1446f58a4a76e16d76aa80329d1981cb32 Fix Issue 17553 - std.json should not do UTF decoding

[Issue 17622] inline for m64 fails web APPS

https://issues.dlang.org/show_bug.cgi?id=17622 steven kladitis changed: What|Removed |Added Keywords||dll ---

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

https://issues.dlang.org/show_bug.cgi?id=17622 Issue ID: 17622 Summary: inline for m64 fails web APPS Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: major Priority: P1

Re: D for mobile development

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

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

On 7/7/17 9:51 PM, Mike Parker wrote: On Saturday, 8 July 2017 at 01:28:59 UTC, Walter Bright wrote: On 7/7/2017 4:35 PM, Nicholas Wilson wrote: It's an intrinsic in LDC. We can certainly drop the per platform and move to a per compiler definition instead. It's already there under:

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

On Saturday, 8 July 2017 at 01:31:54 UTC, Seb wrote: On Saturday, 8 July 2017 at 01:01:38 UTC, Vladimir Panteleev wrote: On Saturday, 8 July 2017 at 00:55:46 UTC, FoxyBrown wrote: It would be easy to find all the bad asserts? Does Dscanner have a rule to detect assert and enforce calls

problem overloading functions with complex enum type

import std.stdio; enum A : int { a, b }; enum B : int { a, b }; enum AS : string[2] { a = ["1","2"], b = ["3","4"] }; enum BS : string[2] { a = ["5","6"], b = ["7","8"] }; void func(A a) { writeln("A"); } void func(B b) { writeln("B"); } void funcs(AS a) { writeln("AS"); } void funcs(BS

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

https://issues.dlang.org/show_bug.cgi?id=17621 Issue ID: 17621 Summary: Don't use deprecated stuff inside Phobos (std/uri.d(338): std.utf.toUTF8) or don't warn the users who are not using it. Product: D Version: D2

Re: proposed @noreturn attribute

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

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:18:38 UTC, Andrei Alexandrescu wrote: On 7/8/17 7:07 AM, bachmeier wrote: On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: Having an @noreturn attribute will take care of that: @noreturn void ThisFunctionExits(); Why should this be an

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

https://issues.dlang.org/show_bug.cgi?id=7063 Vladimir Panteleev changed: What|Removed |Added Keywords|

Current state of the Garbage Collector

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

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 12:17:57 UTC, Andrei Alexandrescu wrote: On 7/8/17 6:15 AM, Walter Bright wrote: Has anyone a better idea? Does anyone want to write a DIP for this? An attribute is fine. A more PL-minded possibility is to return a specific type: struct None { @disable

Re: proposed @noreturn attribute

On 7/8/17 7:07 AM, bachmeier wrote: On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: Having an @noreturn attribute will take care of that: @noreturn void ThisFunctionExits(); Why should this be an attribute rather than a pragma? So it's part of the summary of the

Re: proposed @noreturn attribute

On 7/8/17 6:15 AM, Walter Bright wrote: Has anyone a better idea? Does anyone want to write a DIP for this? An attribute is fine. A more PL-minded possibility is to return a specific type: struct None { @disable this(); @disable this(this); @disable @property None init(); }

[Issue 17620] dwarfeh(327) fatal error

https://issues.dlang.org/show_bug.cgi?id=17620 Sönke Ludwig changed: What|Removed |Added CC|

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

https://issues.dlang.org/show_bug.cgi?id=16641 --- Comment #4 from Etienne --- I still get this infinite loop problem every now and then. I got around it by auto-launching more processes and killing them every hour, it seems like it happens when my (very busy) application

[Issue 6410] Few common exceptions in std.exception

https://issues.dlang.org/show_bug.cgi?id=6410 greenify changed: What|Removed |Added CC||greeen...@gmail.com ---

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

https://issues.dlang.org/show_bug.cgi?id=16641 Martin Nowak changed: What|Removed |Added Keywords||EH CC|

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

https://issues.dlang.org/show_bug.cgi?id=17620 Issue ID: 17620 Summary: dwarfeh(327) fatal error Product: D Version: D2 Hardware: All OS: Linux Status: NEW Keywords: EH Severity: major

[Issue 17271] dwarfeh(224) fatal error

https://issues.dlang.org/show_bug.cgi?id=17271 Martin Nowak changed: What|Removed |Added Keywords||EH Priority|P1

[Issue 17271] dwarfeh(224) fatal error

https://issues.dlang.org/show_bug.cgi?id=17271 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu

Re: proposed @noreturn attribute

On Saturday, 8 July 2017 at 10:15:39 UTC, Walter Bright wrote: Having an @noreturn attribute will take care of that: @noreturn void ThisFunctionExits(); Why should this be an attribute rather than a pragma? It looks to me that the goal is to pass information to the compiler, and

[Issue 6410] Few common exceptions in std.exception

https://issues.dlang.org/show_bug.cgi?id=6410 --- Comment #4 from Vladimir Panteleev --- I think the only good idea from bearophile's list is OverflowException, as conversion data often comes from user input, and it may be useful to distinguish values that are

  1   2   >