Re: Lifetime tracking

On 03.06.2016 01:12, tsbockman wrote: On Thursday, 2 June 2016 at 23:05:40 UTC, Timon Gehr wrote: Whenever the type checker is using a certain piece of information to check validity of a program, there should be a way to pass that kind of information across function boundaries. Otherwise the

Re: The Case Against Autodecode

On 03.06.2016 20:41, Walter Bright wrote: On 6/3/2016 3:14 AM, Vladimir Panteleev wrote: That's not right either. Cyrillic letters can look slightly different from their latin lookalikes in some circumstances. I'm sure there are extremely good reasons for not using the latin lookalikes in the

Re: Binding contexts

On 03.06.2016 18:36, Vladimir Panteleev wrote: On Friday, 3 June 2016 at 15:14:59 UTC, Timon Gehr wrote: https://github.com/dlang/dmd/pull/3361 ... Interesting. Not sure about this. It seems it should work by analogy with this: struct Test{ int x=2; int foo(){ return x; } int

Re: Andrei's list of barriers to D adoption

On 08.06.2016 02:39, Walter Bright wrote: On 6/7/2016 4:07 PM, Andrei Alexandrescu wrote: It is my opinion that writing off formal proofs of safety is a mistake. Clearly we don't have the capability on the core team to work on such. However, I am very interested if you'd want to lead such an

Re: Andrei's list of barriers to D adoption

On 08.06.2016 01:59, Walter Bright wrote: ... I suspect D has long since passed point where it is too complicated for the rather limited ability of mathematicians to prove things about it. The main reason why it is currently impractical to prove things about D is that D is not really a

Re: Andrei's list of barriers to D adoption

On 07.06.2016 10:54, Walter Bright wrote: On 6/7/2016 1:22 AM, Ola Fosheim Grøstad wrote: So this is solved in modern C++. This is where we diverge. A language isn't safe unless it can mechanically guarantee that unsafe constructs are not used. Saying "don't write unsafe code" in C++ does not

Re: Andrei's list of barriers to D adoption

On 07.06.2016 20:43, jmh530 wrote: Are you trying to say that you shouldn't be allowed to do that? I get an error when I actually call x.a(). @nogc: struct Foo { int* a() { return new int; } } void main() { Foo x; auto y = x.a(); } You'll get the same error for this

Re: Passing private functions to template algorithms

On 07.06.2016 20:45, FreeSlave wrote: I want to bring up this unpleasant topic for discussion, because I'm really tired of hacks I need to do in my code. Look at this snippet: private bool isFileNothrow(string path) { import std.file : isFile; import std.exception : collectException;

Re: Andrei's list of barriers to D adoption

On 07.06.2016 21:52, Walter Bright wrote: On 6/7/2016 11:32 AM, Timon Gehr wrote: The @safe subset should be specified and implemented by inclusion, such that it is obvious that it does the right thing. I don't know what's 'unspecific' about this. Closing holes one-by-one is not the right

Re: Andrei's list of barriers to D adoption

On 08.06.2016 00:44, Walter Bright wrote: On 6/7/2016 11:32 AM, Timon Gehr wrote: mixin("@tru"~"sted void foo(){ ... }"); So grep for mixin, too. Not hard. Huge amounts of false positives.

Re: Andrei's list of barriers to D adoption

On 07.06.2016 22:36, Walter Bright wrote: ... BTW, it is a nice idea to require mathematical proofs of code properties, but real world programming languages have turned out to be remarkably resistant to construction of such proofs. As I recall, Java had initially proven that Java was memory

Re: Andrei's list of barriers to D adoption

On 08.06.2016 00:47, Walter Bright wrote: On 6/7/2016 3:23 PM, Timon Gehr wrote: Obviously they proved the virtual machine itself memory safe, As I recall, the proof was broken, not the implementation. Which time? People do make mistakes and overlook cases with proofs. There's nothing

Re: Andrei's list of barriers to D adoption

On 08.06.2016 01:07, Andrei Alexandrescu wrote: On 6/8/16 12:53 AM, Timon Gehr wrote: On 08.06.2016 00:47, Walter Bright wrote: On 6/7/2016 3:23 PM, Timon Gehr wrote: Obviously they proved the virtual machine itself memory safe, As I recall, the proof was broken, not the implementation.

Re: Monads in D

On 11.06.2016 20:27, deadalnix wrote: Honestly, the whole bind/return is just a giant NIH. >>> and >>= are its symptoms. There is a reason why nobody understands jack shit about monad even after 10s of tutorial when they aren't even hard in any way: because haskell and alike have made all

.stringof

On 12.06.2016 15:52, Timon Gehr wrote: You may very well be right that it would be more consistent to return the name of the alias, but I think what .stringof returns is an independent concern. (Last time I checked, it was completely unspecified anyway btw.) What do you think about the

Re: Passing private functions to template algorithms

On 12.06.2016 13:05, Dicebot wrote: On 06/12/2016 01:55 PM, Timon Gehr wrote: On 12.06.2016 10:28, Dicebot wrote: On 06/07/2016 09:59 PM, Timon Gehr wrote: I think it is obvious that this should work. Visibility checks need to happen during identifier lookup. This lookup is happening in the

Re: Passing private functions to template algorithms

On 12.06.2016 15:52, Timon Gehr wrote: semantics are useful is useful

Re: Monads in D

On 12.06.2016 20:28, Max Samukha wrote: On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad wrote: Input world, output modified world... Geez, why doesn't tutorials on Monads say that before they try to explain it with code? Because IO is just one of many applications of the monad

Re: Lifetime tracking

On 03.06.2016 02:31, Walter Bright wrote: On 6/2/2016 4:29 PM, Timon Gehr wrote: // need to know that lifetime of a ends not after lifetime of b void assign(S,T)(ref S a, T b){ a = b; } void foo(scope int* k){ void bar(){ scope int* x; // need to check that lifetime of x

Re: Passing private functions to template algorithms

On 12.06.2016 10:28, Dicebot wrote: On 06/07/2016 09:59 PM, Timon Gehr wrote: I think it is obvious that this should work. Visibility checks need to happen during identifier lookup. This lookup is happening in the module where isFileNothrow is visible. My understanding is that right now

Re: Andrei's list of barriers to D adoption

On 07.06.2016 20:15, Walter Bright wrote: On 6/7/2016 10:44 AM, Timon Gehr wrote: How do you know that some random @safe PR pulled into your project does not corrupt memory? @trusted and @system are designed to be greppable, $ grep -r "@trusted" * $ grep -r "@system" * i.e. you can look

Re: Andrei's list of barriers to D adoption

On 07.06.2016 17:11, H. S. Teoh via Digitalmars-d wrote: On Tue, Jun 07, 2016 at 02:31:43PM +, Steven Schveighoffer via Digitalmars-d wrote: On Tuesday, 7 June 2016 at 13:47:39 UTC, H. S. Teoh wrote: . I can't seem to find an issue I filed some years ago about @safe needing to be

Re: The Case Against Autodecode

On 31.05.2016 20:30, Andrei Alexandrescu wrote: D's Phobos' handling of UTF is at the code unit code point level (like all of Unicode is portably defined).

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.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 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: 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

decoding foreach

On 02.06.2016 12:38, deadalnix wrote: This, deep down, point at the fact that conversion from/to char types are ill defined. One should be able to convert from char to byte/ubyte but not the other way around. One should be able to convert from byte to short but not from char to wchar. Once

Re: The Case Against Autodecode

On 02.06.2016 15:06, Andrei Alexandrescu wrote: On 06/02/2016 06:42 AM, ZombineDev wrote: On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu wrote: On 06/01/2016 06:09 PM, ZombineDev wrote: Regardless of how different people may call it, it's not what this thread is about. Yes,

Re: The Case Against Autodecode

On 02.06.2016 15:09, Andrei Alexandrescu wrote: You can change string literals to be something other than arrays, and then we have a path forward. But as long as char[] is not an array, we have lost the battle of sanity. Yeah, it's a miracle the language stays glued eh. ... It's not a

Re: The Case Against Autodecode

On 01.06.2016 23:48, Andrei Alexandrescu wrote: On 06/01/2016 05:30 PM, Jack Stouffer wrote: On Wednesday, 1 June 2016 at 19:52:01 UTC, Andrei Alexandrescu wrote: foreach (dchar x; a) {} The latter two do autodecoding, not coversion as the rest of the language. This seems to be a

Re: The Case Against Autodecode

On 02.06.2016 15:48, Marc Schütz wrote: No, I don't want to make string a range of anything, I want to provide an additional overload for joiner() that accepts a const(char)[], and returns a range of chars. If strings are not ranges, returning a range of chars is inconsistent.

Re: Dealing with Autodecode

On 01.06.2016 17:30, Andrei Alexandrescu wrote: On 06/01/2016 11:24 AM, Jonathan M Davis via Digitalmars-d wrote: It seems more like RCString is an optimization for certain types of programs than what you'd want to use by default. You'll always want to use it. The small string optimization

Re: Code security: "auto" / Reason for errors

On 01.06.2016 17:34, deadalnix wrote: On Wednesday, 2 March 2016 at 19:42:02 UTC, Ozan wrote: Hi I despair of "auto var1 = var2"for arrays. Isn't it a open door for errors. Example import std.stdio; void main() { int[] a; foreach(i; 0..10) a ~= i; auto b = a; // correct dlang

RCString

On 01.06.2016 22:43, Andrei Alexandrescu wrote: On 06/01/2016 04:28 PM, Timon Gehr wrote: On 01.06.2016 17:30, Andrei Alexandrescu wrote: On 06/01/2016 11:24 AM, Jonathan M Davis via Digitalmars-d wrote: It seems more like RCString is an optimization for certain types of programs than what

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: The Case Against Autodecode

On 30.05.2016 21:28, Andrei Alexandrescu wrote: On 05/30/2016 03:04 PM, Timon Gehr wrote: On 30.05.2016 18:01, Andrei Alexandrescu wrote: On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should

Re: The Case Against Autodecode

On 30.05.2016 18:01, Andrei Alexandrescu wrote: On 05/28/2016 03:04 PM, Walter Bright wrote: On 5/28/2016 5:04 AM, Andrei Alexandrescu wrote: So it harkens back to the original mistake: strings should NOT be arrays with the respective primitives. An array of code units provides consistency,

Re: inout and opApply

On 20.06.2016 17:09, Steven Schveighoffer wrote: What I would like the compiler to do (and I went over this in my talk), is to allow the compiler to inout-wrap a delegate along with the other inout prameters to the function. That is, for: int opApply(scope int delegate(ref inout T value) dg)

Re: std.experimental.checkedint is ready for comments!

On 15.06.2016 18:40, Andrei Alexandrescu wrote: The only remaining matter is to implement a few preexisting policies (Hook implementations) to implement typical choices (such as the ones present today), and the core algorithms for doing bounded operations. The most interesting algorithms are

Re: Please rid me of this goto

On 23.06.2016 19:22, Andrei Alexandrescu wrote: So I was looking for an efficient exponentiation implementation, and http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at page 54. Stepanov's solution, however, duplicates code, so I eliminated it:

Re: [OT] ...

On 24.06.2016 08:49, H. S. Teoh via Digitalmars-d wrote: >I don't care about any of the limits. ^^ has an essential >discontinuity at (0,0), so the limits don't need to have a bearing on >how you define the value, but if they do, consider that there is only >one direction in which the limit is

Re: Please rid me of this goto

On 24.06.2016 08:11, H. S. Teoh via Digitalmars-d wrote: On Fri, Jun 24, 2016 at 05:22:11AM +0200, Timon Gehr via Digitalmars-d wrote: [...] (BTW: It would be fine with me if 0.0^^0.0 was NaN -- that's a completely different case than the one at hand: pow on integers.) That's even worse. So 0

[OT] 0^^0

On 23.06.2016 21:04, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 08:59:07PM +0200, Timon Gehr via Digitalmars-d wrote: [...] Unrelated comment: 0^^0 should not overflow. Says who? http://www.askamathematician.com/2010/12/q-what-does-00-zero-raised-to-the-zeroth-power

Re: inout and opApply

On 23.06.2016 14:58, Steven Schveighoffer wrote: On 6/21/16 5:19 PM, Timon Gehr wrote: The problem here is that both variants make sense depending on context and there is no syntax to distinguish between them. This proposal interacts in a weird way with IFTI. I know you are probably right,

Re: Please rid me of this goto

On 23.06.2016 23:04, Andrei Alexandrescu wrote: On 06/23/2016 02:59 PM, Timon Gehr wrote: On 23.06.2016 19:22, Andrei Alexandrescu wrote: So I was looking for an efficient exponentiation implementation, and http://www.stepanovpapers.com/PAM.pdf has a nice discussion starting at page 54.

Re: Please rid me of this goto

On 24.06.2016 00:53, H. S. Teoh via Digitalmars-d wrote: >Because 0^^0 = 1, and 1 is representable. > >E.g. n^^m counts the number of functions from an m-set to an n-set, >and there is exactly one function from {} to {}. This argument only works for discrete sets. No, it works for any

Re: Please rid me of this goto

On 24.06.2016 01:18, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: This argument only works for discrete sets. If n and m are reals, you'd need a different argument.

[OT] ...

On 24.06.2016 01:58, H. S. Teoh via Digitalmars-d wrote: On Fri, Jun 24, 2016 at 01:33:46AM +0200, Timon Gehr via Digitalmars-d wrote: On 24.06.2016 00:53, H. S. Teoh via Digitalmars-d wrote: Because 0^^0 = 1, and 1 is representable. E.g. n^^m counts the number of functions from an m-set

Re: Please rid me of this goto

On 24.06.2016 02:14, H. S. Teoh via Digitalmars-d wrote: On Fri, Jun 24, 2016 at 01:58:01AM +0200, Timon Gehr via Digitalmars-d wrote: On 24.06.2016 01:18, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: On Thursday, 23 June

Re: Please rid me of this goto

On 24.06.2016 05:22, Timon Gehr wrote: ... break the laws of physics by arbitrarily defining something to be true when it is not. ... Utter nonsense. (Also note that the 'laws of physics' typically give rise to piecewise analytic functions, and if you only consider analytic functions, 0 ^ 0

Re: Please rid me of this goto

On 24.06.2016 04:36, Smoke Adams wrote: You do realize that e^(-1/t)^t is a counter example? e^(-1/t) -> 0 as t -> 0 t -> 0 as t -> 0 That's not a counterexample to anything I said. ^ is discontinuous at (0,0) and indeed, you can force the limit to an arbitrary value by choosing

Re: extern(C++, ns)

On 01/16/2016 08:09 PM, Walter Bright wrote: On 1/16/2016 6:26 AM, Daniel Murphy wrote: Nobody wants conflicting symbols in a module, and nobody wants to cram all of their C++ namespace bindings inside a single D source file to avoid getting namespace symbol conflicts. D's namespace system

Re: Today was a good day

On 01/13/2016 04:38 AM, Andrei Alexandrescu wrote: On 01/12/2016 08:31 PM, Timon Gehr wrote: ... - getPivot selects indices which depend deterministically on the range length. Therefore afaics it is now possible to create inputs that force quadratic runtime for topN. (E.g. an input can be

Re: topN using a heap

On 01/16/2016 10:28 PM, Ivan Kazmenko wrote: On Saturday, 16 January 2016 at 15:25:50 UTC, Andrei Alexandrescu wrote: ... To summarize: For k< The implementation falls back to topNHeap whenever k is within the first or last ~n/8 elements and therefore is Ω(n log n) on average.

Re: topN using a heap

On 01/17/2016 03:09 AM, Andrei Alexandrescu wrote: On 1/16/16 8:00 PM, Timon Gehr wrote: On 01/16/2016 10:28 PM, Ivan Kazmenko wrote: On Saturday, 16 January 2016 at 15:25:50 UTC, Andrei Alexandrescu wrote: ... To summarize: For k< The implementation falls back to topNHeap whenever k is

Re: topN using a heap

On 01/19/2016 12:55 AM, Ilya wrote: On Monday, 18 January 2016 at 23:53:53 UTC, Timon Gehr wrote: On 01/19/2016 12:50 AM, Ilya wrote: ... 1. Yes, probability of hitting the worst case repeatedly is is practically zero. But RNGs do not change this probability. 2. It is possible to build attack

Re: topN using a heap

On 01/19/2016 12:50 AM, Ilya wrote: ... 1. Yes, probability of hitting the worst case repeatedly is is practically zero. But RNGs do not change this probability. 2. It is possible to build attack for our RNGs, because they are Pseudo-RNGs. --Ilya You also need to predict the seed. How do you

Re: topN using a heap

On 01/19/2016 12:39 AM, Andrei Alexandrescu wrote: On 1/18/16 6:18 PM, Ilya wrote: On Monday, 18 January 2016 at 20:45:56 UTC, Ivan Kazmenko wrote: On Monday, 18 January 2016 at 12:00:10 UTC, Ivan Kazmenko wrote: Here goes the test which shows quadratic behavior for the new version:

Re: topN using a heap

On 01/19/2016 12:51 AM, Ilya wrote: On Monday, 18 January 2016 at 23:49:36 UTC, Andrei Alexandrescu wrote: On 1/18/16 6:44 PM, Ilya wrote: On Monday, 18 January 2016 at 23:27:19 UTC, Ivan Kazmenko wrote: On Monday, 18 January 2016 at 23:18:03 UTC, Ilya wrote: A RNGs don't improve worst case.

Re: topN using a heap

On 01/19/2016 01:12 AM, Ilya wrote: There is already implementation with predictable seed. Proof: https://github.com/D-Programming-Language/phobos/blob/master/std/random.d#L1151 --Ilya The default RNG is seeded with unpredictableSeed. What is the point you are trying to make?

Re: local import hijacking

On 01/18/2016 06:02 PM, Jack Stouffer wrote: Is there a compiled list of issues? 1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of. https://issues.dlang.org/show_bug.cgi?id=1238

Re: topN using a heap

On 01/18/2016 01:00 PM, Ivan Kazmenko wrote: The old version (2.070.0-b2) could not be tricked with it, does it use random? Yes, it selected the pivot uniformly at random using the global RNG. (This is also why the documentation says topN is O(n) in expectation.)

Re: static if enhancement

On 27.06.2016 13:05, cym13 wrote: On Monday, 27 June 2016 at 08:16:18 UTC, Claude wrote: On Saturday, 25 June 2016 at 11:27:01 UTC, cym13 wrote: We are talking about early returns (checking for something and returning as soon as possible) which are a well-known and efficient way to reduce

Re: Slice expressions - exact evaluation order, dollar

On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote: > Evaluation order should be strictly left-to-right. DMD and GDC get it wrong > here. > It is evaluated left-to-right. getBase() -> getLowerBound() -> getUpperBound(). Ah, I see what you mean. I think you

Re: [OT] ...

On 24.06.2016 08:49, H. S. Teoh via Digitalmars-d wrote: ...How do you define "number of functions" when m and n are non-integer? ... I don't. But even when n is an arbitrary real number, I still want empty products to be 1. ... Have a look at this plot:

Re: Slice expressions - exact evaluation order, dollar

On 17.06.2016 21:59, kinke wrote: Most interesting IMO though is the question when the slicee's pointer is to be loaded. This is only relevant if the base is an lvalue and may therefore be modified when evaluating the bound expressions. Should the returned slice be based on the slicee's buffer

Re: Should % ever "overflow"?

On 26.06.2016 02:54, Guillaume Boucher wrote: On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote: Most reasonable is numerator = quotient * divisor + remainder Which means it can be negative. Depends on the definition. If division truncates towards negative infinity, the remainder

Re: Slice expressions - exact evaluation order, dollar

On 26.06.2016 20:08, Iain Buclaw via Digitalmars-d wrote: On 26 June 2016 at 14:33, Timon Gehr via Digitalmars-d <digitalmars-d@puremagic.com> wrote: On 26.06.2016 10:08, Iain Buclaw via Digitalmars-d wrote: Old codegen: _base = *(getBase()); _lwr = getLowerBound(_base.length)

Re: Should % ever "overflow"?

On 24.06.2016 22:33, Andrei Alexandrescu wrote: In a checked environment, division may "overflow", e.g. -6 / 2u must be typed as uint but is not representable properly one. How about remainder? I suppose one can make the argument that remainder should never overflow (save for rhs == 0), Well,

Re: Idempotent partition around median of 5?

On 02/06/2016 02:00 PM, Andrei Alexandrescu wrote: On 02/05/2016 08:58 PM, Timon Gehr wrote: On 02/06/2016 02:39 AM, Andrei Alexandrescu wrote: On 02/04/2016 03:30 PM, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps): What is the minimum number of

Re: Idempotent partition around median of 5?

On 02/05/2016 04:41 PM, Fool wrote: On Thursday, 4 February 2016 at 20:30:57 UTC, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps)[...] One swap usually decomposes into three moves. A cycle of length n can be sorted with n + 1 moves. Corresponding to

Re: Idempotent partition around median of 5?

On 02/05/2016 10:42 PM, Xinok wrote: On Friday, 5 February 2016 at 15:13:56 UTC, tn wrote: On Thursday, 4 February 2016 at 20:30:57 UTC, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps): ... Inspired by this, I made four other versions of the

Re: Idempotent partition around median of 5?

On 02/04/2016 03:46 AM, Xinok wrote: I'm not sure of the max swaps, seems like it could be 4 if done right, but that might be impractical. I believe that's correct. Each swap can move at least one element into it's final position. After three swaps, there may be two elements which are still

Re: Idempotent partition around median of 5?

On 02/04/2016 02:24 AM, Andrei Alexandrescu wrote: This appears a simple problem: given numbers a, b, c, d, e, swap them around so as to place the median in c and partition the others around it. I.e. the postcondition is: a <= c && b <= c && c <= d && c <= e. Searching the Net for this isn't

Re: reduce -> fold?

On 02/04/2016 10:38 AM, Atila Neves wrote: On Wednesday, 3 February 2016 at 21:45:04 UTC, Timon Gehr wrote: On 02/03/2016 09:12 PM, Atila Neves wrote: https://github.com/D-Programming-Language/phobos/pull/3968 I think fold should be nothrow, but maybe that's just me. It's also a massive pain

Re: Idempotent partition around median of 5?

On 02/06/2016 02:39 AM, Andrei Alexandrescu wrote: On 02/04/2016 03:30 PM, Timon Gehr wrote: At most 6 comparisons, <=3 swaps, idempotent (optimal number of swaps): What is the minimum number of comparisons? Thx! -- Andrei There is no partition algorithm that uses <= 5 comparisons in all

Re: An important pull request: accessing shared affix for immutable data

On 13.02.2016 03:35, Andrei Alexandrescu wrote: On 02/12/2016 09:21 PM, Timon Gehr wrote: Const could also mean mutable. This can hence reference the same data as both shared and unshared, which violates the type system. If const comes from mutable, then shared is superfluous leading to extra

Re: An important pull request: accessing shared affix for immutable data

On 13.02.2016 18:42, Andrei Alexandrescu wrote: On 02/13/2016 11:55 AM, Timon Gehr wrote: If you alias the same data as both shared and unshared, the shared version can be sent to another thread which will then modify it, violating the guarantees on the unshared reference. Oh, I understand.

Re: DIP 88: Simple form of named parameters

On 01/26/2016 08:05 AM, xenon325 wrote: Yes. Rule 7 covers that. There's also an example showing the syntax, search for "Template specialization with named parameter". Yes, it does look a bit strange. Just like C++98 used to require space :: is not a token, so no space is required. between

Re: reduce -> fold?

On 02/03/2016 09:12 PM, Atila Neves wrote: https://github.com/D-Programming-Language/phobos/pull/3968 I think fold should be nothrow, but maybe that's just me. It's also a massive pain to make it that way, so I didn't for now. Returning Unqual!(ElementType!R).init makes no sense though. The

Re: reduce -> fold?

On 01/29/2016 02:56 PM, Dragos Carp wrote: On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote: Just to bikeshed a little, I remember that when I first started using std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often. D competes with C++ directly, so do

Re: C++ UFCS update

On 24.02.2016 11:24, Ola Fosheim Grøstad wrote: On Tuesday, 23 February 2016 at 20:49:40 UTC, Timon Gehr wrote: On 23.02.2016 21:35, Ola Fosheim Grøstad wrote: I find it ironic that Walter objects to reusing operators such as "<<" while he is reusing "!" for templates No reusing and no irony

Re: C++ UFCS update

On 24.02.2016 22:31, Ola Fosheim Grøstad wrote: That just a very convenient rewriting of reality, The ultimate validity of the premise does not matter for what I objected to. You were trying to paint Walter's position internally inconsistent in a very specific way that just does not hold

Re: @mutable

On 22.02.2016 19:03, Nick Treleaven wrote: On Monday, 22 February 2016 at 17:28:03 UTC, Guillaume Chatelet wrote: static make() { The return type is missing for the make() function: I'm pretty sure static here works just like 'static auto'. In D I think you can use storage classes (and even

Re: C++ UFCS update

On 23.02.2016 21:35, Ola Fosheim Grøstad wrote: I find it ironic that Walter objects to reusing operators such as "<<" while he is reusing "!" for templates No reusing and no irony here. "!" for template instantiation is a binary usage.

Re: Official compiler

On 26.02.2016 23:41, Walter Bright wrote: On 2/26/2016 1:10 PM, Timon Gehr wrote: Different passes are not really required once semantic analysis becomes asynchronous. Just keep track of semantic analysis dependencies, with strong and weak dependencies and different means to resolve cycles of

Re: Choosing arity of a template function

On 27.02.2016 01:03, Jonathan M Davis wrote: There's nothing cheating about using __traits(compiles). It's basically the same as using is(typeof(foo)) and is(typeof({statement;})), albeit arguably a bit more explicit about the fact that it's testing what compiles. The two are subtly different

Re: Official compiler

On 26.02.2016 19:34, Iain Buclaw via Digitalmars-d wrote: On 26 Feb 2016 9:45 am, "Walter Bright via Digitalmars-d" > wrote: > > On 2/26/2016 12:20 AM, Iain Buclaw via Digitalmars-d wrote: >> >> I thought that mulithreaded I/O

Re: Unum II announcement

On 24.02.2016 00:52, Nicholas Wilson wrote: On Tuesday, 23 February 2016 at 20:22:19 UTC, jmh530 wrote: On Monday, 22 February 2016 at 05:08:13 UTC, Nick B wrote: I strongly recommend that you download the presentation [Powerpoint, 35 pages] as there are lots of Notes with the presentation.

Re: C++ UFCS update

On 24.02.2016 23:10, Ola Fosheim Grøstad wrote: On Wednesday, 24 February 2016 at 21:56:12 UTC, Timon Gehr wrote: The ultimate validity of the premise does not matter for what I objected to. You were trying to paint Walter's position internally inconsistent in a very specific way that just does

Re: Compile-Time RNG

On 01/21/2016 01:32 AM, tsbockman wrote: On Wednesday, 20 January 2016 at 23:21:04 UTC, CTRNG wrote: I managed to create a compile-time random number generator. Proof of concept, with some explanatory comments: http://dpaste.dzfl.pl/668646ce6d71 Just thought this might be of interest to some

Re: rval->ref const(T), implicit conversions

On 01/19/2016 06:43 AM, bitwise wrote: Finally, this situation simply should not be this complicated. A ref param should accept an rvalue. @safety is a specific concern, and unless I'm annotating my code with @safe, I should be able to write it however I want(within reason). To quote a famous

Re: rval->ref const(T), implicit conversions

On 01/19/2016 07:43 PM, bitwise wrote: On Tuesday, 19 January 2016 at 18:30:26 UTC, Timon Gehr wrote: On 01/19/2016 06:43 AM, bitwise wrote: Finally, this situation simply should not be this complicated. A ref param should accept an rvalue. @safety is a specific concern, and unless I'm

Re: topN using a heap

On 01/19/2016 04:33 PM, Andrei Alexandrescu wrote: On 01/19/2016 08:10 AM, Andrei Alexandrescu wrote: So anyhow we need the "intro" part. I'll get to that soon. Destroy! I made it part of https://github.com/D-Programming-Language/phobos/pull/3934.

Re: Why do some attributes start with '@' while others done't?

On 01/22/2016 03:20 AM, Dicebot wrote: I'd definitely place something like `@safe` in type constructors @safe(int) ?

Re: medianOfMedians

On 01/20/2016 02:20 AM, Andrei Alexandrescu wrote: I've seldom have code write itself so beautifully. Which, of course, means it needs to be destroyed. https://github.com/D-Programming-Language/phobos/pull/3938 -- Andrei This is not an implementation of the median of medians algorithm. int[]

Re: extern(C++, ns)

On 01/20/2016 03:25 AM, deadalnix wrote: On Wednesday, 20 January 2016 at 02:15:27 UTC, Manu wrote: The C++ namespace semantic doesn't have a proper analogy in D, and the D code is already organised into modules anyway making mirroring of the C++ semantic irrelevant. We don't mirror C/C++

Re: So... add maxCount and maxPos?

On 01/20/2016 06:29 PM, H. S. Teoh via Digitalmars-d wrote: On Wed, Jan 20, 2016 at 12:16:00PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: This is one of those cases in which we were pedantically right to not add them, but their equivalents look like crap.

Re: extern(C++, ns)

On 01/20/2016 09:56 PM, Walter Bright wrote: On 1/20/2016 4:17 AM, Manu via Digitalmars-d wrote: -- name.x.d module name.x; -- name.y.d module name.y; import name.x; extern(C++, name) int x; This won't work ...

<    4   5   6   7   8   9   10   11   12   13   >