Re: Dealing with Autodecode

On Wednesday, 1 June 2016 at 01:36:43 UTC, Adam D. Ruppe wrote: D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE QUALITY WITH A SIMPLE MIGRATION PATH This. I only recently started full scale use of D, but I lurked here for years. D has a few quirks here and

Re: D Embedded Database v0.1 Released

On Tuesday, 31 May 2016 at 22:08:00 UTC, Stefan Koch wrote: Nice effort. How would you like collaboration with the SQLite-D project. Thanks. Correct me if I'm wrong but SQLite-D is a compile time SQLite3 file reader. If so, I can predict not many common parts. Maybe the one would be a data

[Issue 15885] float serialized to JSON loses precision

https://issues.dlang.org/show_bug.cgi?id=15885 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/7a486d9d038448595c74aa4ef4bd7d9e952a4b64 Fix issue 15885 - numeric values serialized to JSON

[Issue 15885] float serialized to JSON loses precision

https://issues.dlang.org/show_bug.cgi?id=15885 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED

Re: The Case Against Autodecode

On 5/31/2016 4:00 PM, ag0aep6g wrote: Wikipedia says [1] that UCS-2 is essentially UTF-16 without surrogate pairs. I suppose you mean UTF-32/UCS-4. [1] https://en.wikipedia.org/wiki/UTF-16 Thanks for the correction.

Re: The Case Against Autodecode

On Wednesday, 1 June 2016 at 02:17:21 UTC, Jonathan M Davis wrote: ... This thread is going in circles; the against crowd has stated each of their arguments very clearly at least five times in different ways. The cost/benefit problems with auto decoding are as clear as day. If the

Re: Dealing with Autodecode

On Wednesday, 1 June 2016 at 02:58:36 UTC, Brad Roberts wrote: ...the rate of bug fixing which exceeds the rate of fix pulling. Speaking of which: https://github.com/dlang/phobos/pull/4345 https://github.com/dlang/phobos/pull/3973

Re: Reddit announcements

On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. Thank you for doing this! I agree previous posts though, that this is too many at once. Also, I think posting a link directly to the project instead of the forum post

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

https://issues.dlang.org/show_bug.cgi?id=16107 --- Comment #1 from b2.t...@gmx.com --- definition of Foo can be reduced to class Foo { alias TreeItemType = typeof(this); TreeItemSiblings!TreeItemType _siblings;// remove this decl TreeItemChildren!TreeItemType _children;// or

Re: Button: A fast, correct, and elegantly simple build system.

On Tuesday, 31 May 2016 at 14:28:02 UTC, Dicebot wrote: Can it be built from just plain dmd/phobos install available? One of major concernc behind discussion that resulted in Atila reggae effort is that propagating additional third-party dependencies is very damaging for build systems. Right

[Issue 16107] New: [ICE] - Internal error: backend/cgcod.c 2297

https://issues.dlang.org/show_bug.cgi?id=16107 Issue ID: 16107 Summary: [ICE] - Internal error: backend/cgcod.c 2297 Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: critical

Re: Button: A fast, correct, and elegantly simple build system.

On Tuesday, 31 May 2016 at 10:15:14 UTC, Atila Neves wrote: On Monday, 30 May 2016 at 19:16:50 UTC, Jason White wrote: I am pleased to finally announce the build system I've been slowly working on for over a year in my spare time: snip In fact, there is some experimental support for automatic

Re: Button: A fast, correct, and elegantly simple build system.

On Tuesday, 31 May 2016 at 03:40:32 UTC, rikki cattermole wrote: Are you on Freenode (no nick to name right now)? I would like to talk to you about a few ideas relating to lua and D. No, I'm not on IRC. I'll see if I can find the time to hop on this weekend.

Re: Dealing with Autodecode

On 5/31/2016 7:40 PM, Walter Bright via Digitalmars-d wrote: On 5/31/2016 7:28 PM, Jonathan M Davis via Digitalmars-d wrote: The other critical thing is to make sure that Phobos in general works with byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started trying to use

Re: Dealing with Autodecode

On 5/31/2016 7:28 PM, Jonathan M Davis via Digitalmars-d wrote: The other critical thing is to make sure that Phobos in general works with byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started trying to use byCodeUnit instead of naked strings, I ran into this:

Re: Dealing with Autodecode

On 5/31/2016 6:36 PM, Adam D. Ruppe wrote: Our preliminary investigation found about 130 places in Phobos that need to be changed. That's not hard to fix! PRs please!

Re: Dealing with Autodecode

On 05/31/2016 09:36 PM, Adam D. Ruppe wrote: version(string_migration) deprecated void popFront(T)(ref T t) if(isSomeString!T) { static assert(0, "this is crap, fix your code."); } else deprecated("use -versionstring_migration to fix your buggy code, would you like to know more?") /*

Re: Dealing with Autodecode

On Tuesday, May 31, 2016 17:46:04 Walter Bright via Digitalmars-d wrote: > It is not practical to just delete or deprecate autodecode - it is too > embedded into things. What we can do, however, is stop using it ourselves > and stop relying on it in the documentation, much like [] is eschewed in >

Re: Reddit announcements

On 5/31/16 2:57 PM, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/ https://www.reddit.com/r/programming/comments/4lwubv/c_to_d_converter_based_on_clang/

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 23:36:20 Marco Leise via Digitalmars-d wrote: > Am Tue, 31 May 2016 16:56:43 -0400 > > schrieb Andrei Alexandrescu : > > On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote: > > > In the vast majority of cases what folks care

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 20:38:14 Nick Sabalausky via Digitalmars-d wrote: > On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote: > > On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote: > >> On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote: > >>> Let's put the question this way. Given the

Re: Variables should have the ability to be @nogc

On Tuesday, 31 May 2016 at 23:46:59 UTC, Marco Leise wrote: Am Tue, 31 May 2016 20:41:09 + schrieb Basile B. : The only thing is that I'm not sure about is the tri-state and the recursion. I cannot find a case where it would be justified. The recursion is simply there

Re: Dealing with Autodecode

On Wednesday, 1 June 2016 at 00:46:04 UTC, Walter Bright wrote: It is not practical to just delete or deprecate autodecode Yes, it is. We need to stop holding on to the mistakes of the past. 9 of 10 dentists agree that autodecoding is a mistake. Not just WAS a mistake, IS a mistake. It has

Re: Free the DMD backend

On Tuesday, 31 May 2016 at 20:18:34 UTC, default0 wrote: I have no idea how licensing would work in that regard but considering that DMDs backend is actively maintained and may eventually even be ported to D, wouldn't it at some point differ enough from Symantecs "original" backend to simply

Re: Dealing with Autodecode

On 5/31/2016 5:56 PM, Stefan Koch wrote: It is only going to get harder to remove it. Removing it from Phobos and adjusting the documentation as I suggested is the way forward regardless. If we can't get that done, how can we tell our users they have to do the same to their code?

Re: Transient ranges

On 5/31/16 4:59 PM, Dicebot wrote: On Tuesday, 31 May 2016 at 18:11:34 UTC, Steven Schveighoffer wrote: 1) Current definition of input range (most importantly, the fact `front` has to be @property-like) implies `front` to always return the same result until `popFront` is called. Regardless of

Re: Free the DMD backend

On Tuesday, 31 May 2016 at 20:12:33 UTC, Russel Winder wrote: On Tue, 2016-05-31 at 10:09 +, Atila Neves via Digitalmars-d wrote:  […] No, no, no, no. We had LDC be the default already on Arch Linux for a while and it was a royal pain. I want to choose to use LDC when and if I need

Re: Dealing with Autodecode

On 5/31/16 8:46 PM, Walter Bright wrote: It is not practical to just delete or deprecate autodecode - it is too embedded into things. What we can do, however, is stop using it ourselves and stop relying on it in the documentation, much like [] is eschewed in favor of std::vector in C++. The way

Re: The Case Against Autodecode

On 5/31/16 4:38 PM, Timon Gehr wrote: On 31.05.2016 21:51, Steven Schveighoffer wrote: On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] Does walkLength yield the same number for all

Re: Dealing with Autodecode

On Wednesday, 1 June 2016 at 00:46:04 UTC, Walter Bright wrote: It is not practical to just delete or deprecate autodecode - it is too embedded into things. Which Things ? The way to deal with it is to replace reliance on autodecode with .byDchar (.byDchar has a bonus of not throwing an

Dealing with Autodecode

It is not practical to just delete or deprecate autodecode - it is too embedded into things. What we can do, however, is stop using it ourselves and stop relying on it in the documentation, much like [] is eschewed in favor of std::vector in C++. The way to deal with it is to replace reliance

Re: The Case Against Autodecode

On 05/31/2016 01:23 PM, Andrei Alexandrescu wrote: On 05/31/2016 01:15 PM, Jonathan M Davis via Digitalmars-d wrote: The standard library has to fight against itself because of autodecoding! The vast majority of the algorithms in Phobos are special-cased on strings in an attempt to get around

Re: The Case Against Autodecode

On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote: On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote: On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote: Let's put the question this way. Given the following string, what do *you* think walkLength should return? şŭt̥ḛ́k̠ The

Re: The Case Against Autodecode

On 5/31/2016 1:57 AM, Chris wrote: 1. Given you experience with Warp, how hard would it be to clean Phobos up? It's not hard, it's just a bit tedious. 2. After recoding a number of Phobos functions, how much code did actually break (yours or someone else's)?. It's been a while so I don't

Re: Reddit announcements

On Tuesday, 31 May 2016 at 20:47:39 UTC, cym13 wrote: On Tuesday, 31 May 2016 at 19:33:46 UTC, John Colvin wrote: On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit.

Re: Split general into multiple threads

On Sunday, 29 May 2016 at 11:44:25 UTC, ZombineDev wrote: On Sunday, 29 May 2016 at 11:35:12 UTC, Seb wrote: [...] I like this list better than the current, but with one change: taking LDC out of core and renaming it to LDC and LLVM so other D projects that leverage LLVM can be hosted there

Re: year to date pull statistics (week ending 2016-05-28)

On Tuesday, 31 May 2016 at 23:48:00 UTC, Brad Roberts wrote: total open: 252 created since 2016-01-01 and still open: 106 ... total open: 284 created since 2016-01-01 and still open: 142 Ouch - that's a huge spike! What happened to the idea from dconf to automatically assing PR managers

Re: Variables should have the ability to be @nogc

Am Tue, 31 May 2016 20:41:09 + schrieb Basile B. : > The only thing is that I'm not sure about is the tri-state and > the recursion. I cannot find a case where it would be justified. The recursion is simply there to find pointers in nested structs and their GcScan

Re: year to date pull statistics (week ending 2016-05-28)

total open: 284 created since 2016-01-01 and still open: 142 created closed delta 2016-05-29 - today 25 25 0 2016-05-22 - 2016-05-28 46 34-12 2016-05-15 - 2016-05-21 40 36 -4 2016-05-08 - 2016-05-14 82 55-27

[OT] UTF-16

Am Tue, 31 May 2016 15:47:02 -0700 schrieb Walter Bright : > But I didn't know which encoding would win - UTF-8, UTF-16, or UCS-2, so D > bet > on all three. If I had a do-over, I'd just support UTF-8. UTF-16 is useful > pretty much only as a transitional encoding

Re: The Case Against Autodecode

On 06/01/2016 12:47 AM, Walter Bright wrote: But I didn't know which encoding would win - UTF-8, UTF-16, or UCS-2, so D bet on all three. If I had a do-over, I'd just support UTF-8. UTF-16 is useful pretty much only as a transitional encoding to talk with Windows APIs. Nobody uses UCS-2 (it

Re: faster splitter

On Tuesday, 31 May 2016 at 21:29:34 UTC, Andrei Alexandrescu wrote: You may want to then try https://dpaste.dzfl.pl/392710b765a9, which generates inline code on all compilers. -- Andrei In general, it might be beneficial to use ldc.intrinsics.llvm_expect (cf. __builtin_expect) for things like

Re: The Case Against Autodecode

On 5/31/2016 1:20 PM, Marco Leise wrote: [...] I agree. I dealt the madness of code pages, Shift-JIS, EBCDIC, locales, etc., in the pre-Unicode days. Despite its problems, Unicode (and UTF-8) is a major improvement, and I mean major. 16 years ago, I bet that Unicode was the future, and

Re: D Embedded Database v0.1 Released

On Saturday, 28 May 2016 at 14:08:18 UTC, Piotrek wrote: Short description A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges. Design Goals (none is accomplished yet) - ACID - No external dependencies - Single file

Re: Our Sister

Am Wed, 1 Jun 2016 01:06:36 +1000 schrieb Manu via Digitalmars-d : > D loves templates, but templates aren't a given. Closed-source > projects often can't have templates in the public API (ie, source > should not be available), and this is my world. Same effect for

Re: The Case Against Autodecode

Am Tue, 31 May 2016 16:56:43 -0400 schrieb Andrei Alexandrescu : > On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote: > > In the vast majority of cases what folks care about is full character > > How are you so sure? -- Andrei Because a full

Re: Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments

On Tuesday, 31 May 2016 at 20:46:37 UTC, Basile B. wrote: Yes this can be done, you must use the getOverload trait: https://dlang.org/spec/traits.html#getOverloads The result of this trait is the function itself so it's not hard to use, e.g the result can be passed directly to 'Parameters',

Re: Transient ranges

On Tuesday, 31 May 2016 at 21:25:12 UTC, Timon Gehr wrote: On 31.05.2016 22:59, Dicebot wrote: I think we should be aware that the range API doesn't prevent bugs of all kinds. There's only so much analysis the compiler can do. This is a totally valid code I want to actually work and not

Re: faster splitter

On 05/31/2016 04:18 PM, Chris wrote: I actually thought that dmd didn't place `computeSkip` inside of the loop. This begs the question if it should be moved to the loop, in case we use it in Phobos, to make sure that it is as fast as possible even with dmd. However, I like it the way it is now.

Re: Transient ranges

On 31.05.2016 22:59, Dicebot wrote: I think we should be aware that the range API doesn't prevent bugs of all kinds. There's only so much analysis the compiler can do. This is a totally valid code I want to actually work and not be discarded as "bug". map often allows random access. Do

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 21:01:17 UTC, Andrei Alexandrescu wrote: If user code needs to go upper at the grapheme level, they can If anything this thread strengthens my opinion that autodecoding is a sweet spot. -- Andrei Unicode FAQ disagrees (http://unicode.org/faq/utf_bom.html): "Q:

Re: The Case Against Autodecode

On Tue, May 31, 2016 at 05:01:17PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: > On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote: > > Wasn't the whole point of operating at the code point level by > > default to make it so that code would be operating on full > >

Re: The Case Against Autodecode

Am Tue, 31 May 2016 13:06:16 -0400 schrieb Andrei Alexandrescu : > On 05/31/2016 12:54 PM, Jonathan M Davis via Digitalmars-d wrote: > > Equality does not require decoding. Similarly, functions like find don't > > either. Something like filter generally would, but

Re: The Case Against Autodecode

On 31.05.2016 22:20, Marco Leise wrote: Am Tue, 31 May 2016 16:29:33 + schrieb Joakim: >Part of it is the complexity of written language, part of it is >bad technical decisions. Building the default string type in D >around the horrible UTF-8 encoding was a

Re: The Case Against Autodecode

On 05/31/2016 04:01 PM, Jonathan M Davis via Digitalmars-d wrote: Wasn't the whole point of operating at the code point level by default to make it so that code would be operating on full characters by default instead of chopping them up as is so easy to do when operating at the code unit level?

Re: Transient ranges

On Tuesday, 31 May 2016 at 18:11:34 UTC, Steven Schveighoffer wrote: 1) Current definition of input range (most importantly, the fact `front` has to be @property-like) implies `front` to always return the same result until `popFront` is called. Regardless of property-like or not, this should

Re: The Case Against Autodecode

On 05/31/2016 03:44 PM, Jonathan M Davis via Digitalmars-d wrote: In the vast majority of cases what folks care about is full character How are you so sure? -- Andrei

Re: The Case Against Autodecode

On 05/31/2016 03:34 PM, ag0aep6g wrote: On 05/31/2016 07:21 PM, Andrei Alexandrescu wrote: Could you please substantiate that? My understanding is that code unit is a higher-level Unicode notion independent of encoding, whereas code point is an encoding-dependent representation detail. --

Re: The Case Against Autodecode

On 05/31/2016 04:55 PM, Andrei Alexandrescu wrote: On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote: Let's put the question this way. Given the following string, what do *you* think walkLength should return? şŭt̥ḛ́k̠ The number of code units in the string. That's the

Re: The Case Against Autodecode

On 05/31/2016 03:32 PM, H. S. Teoh via Digitalmars-d wrote: Let's put the question this way. Given the following string, what do *you* think walkLength should return? şŭt̥ḛ́k̠ The number of code units in the string. That's the contract promised and honored by Phobos. -- Andrei

Re: Is there any overhead iterating over a pointer using a slice?

On Tuesday, 31 May 2016 at 18:55:18 UTC, Gary Willoughby wrote: If I have a pointer and iterate over it using a slice, like this: T* foo = foreach (element; foo[0 .. length]) { ... } Is there any overhead compared with pointer arithmetic in

[Issue 15371] __traits(getMember) should bypass the protection

https://issues.dlang.org/show_bug.cgi?id=15371 --- Comment #4 from b2.t...@gmx.com --- In the meantime, when the trait code is for a struct or a class it's possible to use its '.tupleof' property. It's not affected by the visibility. Instead of all member: import std.meta: aliasSeqOf;

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 20:28:32 UTC, ag0aep6g wrote: On 05/31/2016 06:29 PM, Joakim wrote: D devs should lead the way in getting rid of the UTF-8 encoding, not bickering about how to make it more palatable. I suggested a single-byte encoding for most languages, with double-byte for the

Re: The Case Against Autodecode

On Tue, May 31, 2016 at 10:38:03PM +0200, Timon Gehr via Digitalmars-d wrote: > On 31.05.2016 21:51, Steven Schveighoffer wrote: > > On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote: > > > On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via > > > Digitalmars-d wrote: > > >

Re: Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments

On Tuesday, 31 May 2016 at 20:06:47 UTC, pineapple wrote: I'd like to find the overload of some function with the most parameters and (in this specific case) to get their identifiers using e.g. ParameterIdentifierTuple. There have also been cases where I'd have liked to iterate over the result

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 20:20:46 UTC, Marco Leise wrote: Am Tue, 31 May 2016 16:29:33 + schrieb Joakim : Part of it is the complexity of written language, part of it is bad technical decisions. Building the default string type in D around the horrible UTF-8

Re: Reddit announcements

On Tuesday, 31 May 2016 at 19:33:46 UTC, John Colvin wrote: On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/

Re: Variables should have the ability to be @nogc

On Tuesday, 31 May 2016 at 19:04:39 UTC, Marco Leise wrote: Am Tue, 31 May 2016 15:53:44 + schrieb Basile B. : This solution seems smarter than using the existing '@nogc' attribute. Plus one also for the fact that nothing has to be done in DMD. I just constrained myself

Re: The Case Against Autodecode

On Tue, May 31, 2016 at 10:47:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote: > On 31-May-2016 01:00, Walter Bright wrote: > > On 5/30/2016 11:25 AM, Adam D. Ruppe wrote: > > > I don't agree on changing those. Indexing and slicing a char[] is > > > really useful and actually not hard to do

Re: The Case Against Autodecode

On 31.05.2016 21:51, Steven Schveighoffer wrote: On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] Does walkLength yield the same number for all representations? Let's put the question this

Re: The Case Against Autodecode

On 05/31/2016 06:29 PM, Joakim wrote: D devs should lead the way in getting rid of the UTF-8 encoding, not bickering about how to make it more palatable. I suggested a single-byte encoding for most languages, with double-byte for the ones which wouldn't fit in a byte. Use some kind of header

Re: D Embedded Database v0.1 Released

On Saturday, 28 May 2016 at 14:08:18 UTC, Piotrek wrote: Short description A database engine for quick and easy integration into any D program. Full compatibility with D types and ranges. Design Goals (none is accomplished yet) - ACID - No external dependencies - Single file

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 18:34:54 UTC, Jonathan M Davis wrote: On Tuesday, May 31, 2016 16:29:33 Joakim via Digitalmars-d wrote: UTF-8 is an antiquated hack that needs to be eradicated. It forces all other languages than English to be twice as long, for no good reason, have fun with that

Re: The Case Against Autodecode

Am Tue, 31 May 2016 16:29:33 + schrieb Joakim : > Part of it is the complexity of written language, part of it is > bad technical decisions. Building the default string type in D > around the horrible UTF-8 encoding was a fundamental mistake, > both in terms of

Re: asm woes...

On Tuesday, 31 May 2016 at 18:52:16 UTC, Marco Leise wrote: The 'this' pointer is usually in some register already. On Linux 32-bit for example it is in EAX, on Linux 64-bit is in RDI. The AX register seems like a bad choice, since you require the AX/DX registers when you do multiplication

Re: faster splitter

On Tuesday, 31 May 2016 at 19:59:50 UTC, qznc wrote: On Tuesday, 31 May 2016 at 19:29:25 UTC, Chris wrote: Would it speed things up even more, if we put the function `computeSkip` into the loop or is this done automatically by the compiler? LDC inlines it. DMD does not. More numbers:

Re: Free the DMD backend

I have no idea how licensing would work in that regard but considering that DMDs backend is actively maintained and may eventually even be ported to D, wouldn't it at some point differ enough from Symantecs "original" backend to simply call the DMD backend its own thing? Or are all the

Re: Free the DMD backend

On Tue, 2016-05-31 at 10:09 +, Atila Neves via Digitalmars-d wrote: > […] > > No, no, no, no. We had LDC be the default already on Arch Linux  > for a while and it was a royal pain. I want to choose to use LDC  > when and if I need performance. Otherwise, I want my projects to  > compile as

Getting the parameters and other attributes belonging to the function overload with the greatest number of arguments

I'd like to find the overload of some function with the most parameters and (in this specific case) to get their identifiers using e.g. ParameterIdentifierTuple. There have also been cases where I'd have liked to iterate over the result of Parameters!func for each overload of that function.

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 22:47:56 Dmitry Olshansky via Digitalmars-d wrote: > On 31-May-2016 01:00, Walter Bright wrote: > > On 5/30/2016 11:25 AM, Adam D. Ruppe wrote: > >> I don't agree on changing those. Indexing and slicing a char[] is > >> really useful > >> and actually not hard to do

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 21:48:36 Timon Gehr via Digitalmars-d wrote: > On 31.05.2016 21:40, Wyatt wrote: > > On Tuesday, 31 May 2016 at 19:20:19 UTC, Timon Gehr wrote: > >> The 'length' of a character is not one in all contexts. > >> The following text takes six columns in my terminal: > >> > >>

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 15:33:38 Andrei Alexandrescu via Digitalmars-d wrote: > On 05/31/2016 02:53 PM, Jonathan M Davis via Digitalmars-d wrote: > > walkLength treats a code point like it's a character. > > No, it treats a code point like it's a code point. -- Andrei Wasn't the whole point of

Re: faster splitter

On Tuesday, 31 May 2016 at 19:29:25 UTC, Chris wrote: Would it speed things up even more, if we put the function `computeSkip` into the loop or is this done automatically by the compiler? LDC inlines it. DMD does not. More numbers: ./benchmark.ldc Search in Alice in Wonderland std:

Re: The Case Against Autodecode

On 5/31/16 3:32 PM, H. S. Teoh via Digitalmars-d wrote: On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] Does walkLength yield the same number for all representations? Let's put the question this way. Given the following string, what do *you* think

Re: The Case Against Autodecode

On Tue, May 31, 2016 at 07:40:13PM +, Wyatt via Digitalmars-d wrote: > On Tuesday, 31 May 2016 at 19:20:19 UTC, Timon Gehr wrote: > > > > The 'length' of a character is not one in all contexts. > > The following text takes six columns in my terminal: > > > > 日本語 > > 123456 > > That's a

Re: The Case Against Autodecode

On 31.05.2016 21:40, Wyatt wrote: On Tuesday, 31 May 2016 at 19:20:19 UTC, Timon Gehr wrote: The 'length' of a character is not one in all contexts. The following text takes six columns in my terminal: 日本語 123456 That's a property of your font and font rendering engine, not Unicode. Sure.

Re: The Case Against Autodecode

On 31-May-2016 01:00, Walter Bright wrote: On 5/30/2016 11:25 AM, Adam D. Ruppe wrote: I don't agree on changing those. Indexing and slicing a char[] is really useful and actually not hard to do correctly (at least with regard to handling code units). Yup. It isn't hard at all to use arrays

Re: The Case Against Autodecode

On Tuesday, May 31, 2016 21:20:19 Timon Gehr via Digitalmars-d wrote: > On 31.05.2016 20:53, Jonathan M Davis via Digitalmars-d wrote: > > On Tuesday, May 31, 2016 14:30:08 Andrei Alexandrescu via Digitalmars-d wrote: > >> >On 5/31/16 2:11 PM, Jonathan M Davis via Digitalmars-d wrote: > >>> > >On

Re: The Case Against Autodecode

On Tuesday, 31 May 2016 at 19:20:19 UTC, Timon Gehr wrote: The 'length' of a character is not one in all contexts. The following text takes six columns in my terminal: 日本語 123456 That's a property of your font and font rendering engine, not Unicode. (Also, it's probably not quite six

[Issue 16090] popFront generates out-of-bounds array index on corrupted utf-8 strings

https://issues.dlang.org/show_bug.cgi?id=16090 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/e1af1b0b51ea9f29d4ff8076d73c03ba10bfc73c fix issue 16090 - popFront generates out-of-bounds

Re: The Case Against Autodecode

On Tue, May 31, 2016 at 02:30:08PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] > Does walkLength yield the same number for all representations? Let's put the question this way. Given the following string, what do *you* think walkLength should return? şŭt̥ḛ́k̠ I think

Re: The Case Against Autodecode

On 05/31/2016 07:21 PM, Andrei Alexandrescu wrote: Could you please substantiate that? My understanding is that code unit is a higher-level Unicode notion independent of encoding, whereas code point is an encoding-dependent representation detail. -- Andrei You got the terms mixed up. Code unit

Re: The Case Against Autodecode

On 05/31/2016 02:57 PM, Jonathan M Davis via Digitalmars-d wrote: In addition, as soon as you have ubyte[], none of the string-related functions work. That's fixable, but as it stands, operating on ubyte[] instead of char[] is a royal pain. That'd be nice to fix indeed. Please break the

Re: The Case Against Autodecode

On 05/31/2016 02:53 PM, Jonathan M Davis via Digitalmars-d wrote: walkLength treats a code point like it's a character. No, it treats a code point like it's a code point. -- Andrei

Re: The Case Against Autodecode

On 05/31/2016 02:46 PM, Timon Gehr wrote: On 31.05.2016 20:30, Andrei Alexandrescu wrote: D's Phobos' foreach, too. -- Andrei

Re: Reddit announcements

On Tuesday, 31 May 2016 at 18:57:29 UTC, o-genki-desu-ka wrote: Many nice announcements here last week. I put some on reddit. https://www.reddit.com/r/programming/comments/4lwufi/d_embedded_database_v01_released/

Re: faster splitter

On Tuesday, 31 May 2016 at 18:56:14 UTC, qznc wrote: The mistake is to split on "," instead of ','. The slow splitter at the start of this thread searches for "\r\n". Your lazy-skip algorithm looks great! ./benchmark.ldc Search in Alice in Wonderland std: 168 ±6 +29 ( 107) -3

Re: The Case Against Autodecode

On 31.05.2016 20:53, Jonathan M Davis via Digitalmars-d wrote: On Tuesday, May 31, 2016 14:30:08 Andrei Alexandrescu via Digitalmars-d wrote: >On 5/31/16 2:11 PM, Jonathan M Davis via Digitalmars-d wrote: > >On Tuesday, May 31, 2016 13:21:57 Andrei Alexandrescu via Digitalmars-d wrote: >

Re: Variables should have the ability to be @nogc

Am Tue, 31 May 2016 15:53:44 + schrieb Basile B. : > This solution seems smarter than using the existing '@nogc' > attribute. Plus one also for the fact that nothing has to be done > in DMD. I just constrained myself to what can be done in user code from the start. :) >

Is there any overhead iterating over a pointer using a slice?

In relation to this thread: http://forum.dlang.org/thread/ddckhvcxlyuvuiyaz...@forum.dlang.org Where I asked about slicing a pointer, I have another question: If I have a pointer and iterate over it using a slice, like this: T* foo = foreach (element; foo[0 .. length])

  1   2   3   >