Re: DIP60: @nogc attribute

2014-04-16 Thread Timon Gehr via Digitalmars-d
On 04/16/2014 10:10 PM, Peter Alexander wrote: However, that raises a second question: since err is allocated when a new thread is created, does that mean @nogc functions cannot create threads in the presence of such static initialisation? This does not allocate on the GC heap.

Re: DIP60: @nogc attribute

2014-04-17 Thread Timon Gehr via Digitalmars-d
On 04/17/2014 02:34 PM, Manu via Digitalmars-d wrote: On 17 April 2014 21:57, John Colvin via Digitalmars-d digitalmars-d@puremagic.com mailto:digitalmars-d@puremagic.com wrote: On Thursday, 17 April 2014 at 11:31:52 UTC, Manu via Digitalmars-d wrote: ARC offers a solution that

Re: Knowledge of managed memory pointers

2014-04-17 Thread Timon Gehr via Digitalmars-d
On 04/17/2014 08:55 AM, Manu via Digitalmars-d wrote: It occurs to me that a central issue regarding the memory management debate, and a major limiting factor with respect to options, is the fact that, currently, it's impossible to tell a raw pointer apart from a gc pointer. Is this is a

Re: DIP60: @nogc attribute

2014-04-18 Thread Timon Gehr via Digitalmars-d
On 04/18/2014 10:50 AM, bearophile wrote: Honestly, I think expecting that code to be allowed to use @nogc is a huge mistake and disagree with editing the DIP to include this solely because you decided it should. That Wiki page is editable, so if it's wrong it takes one minute to fix the

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 11:31 AM, Walter Bright wrote: http://wiki.dlang.org/DIP61 Best practices in C++ code increasingly means putting functions and declarations in namespaces. Currently, there is no support in D to call C++ functions in namespaces. The primary issue is that the name mangling doesn't

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 01:57 PM, Dicebot wrote: I think this is a very bad proposal. Necessity to define namespaces for interfacing with C++ must not result in usage of namespaces of pure D code. Well, the proposed feature does not add any new capabilities except proper mangling. In pure D code

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 08:13 PM, Walter Bright wrote: private mixin template Foo(){ // declarations } mixin Foo foo; ... I guess namespaces will occur in pure D code as sparsely as the above construction, because they are not particularly useful. Yeah, template mixins turned out to be a solution

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 08:15 PM, Walter Bright wrote: On 4/26/2014 5:37 AM, Timon Gehr wrote: import std.stdio; namespace g{ int foo(int a){ return a; } } namespace g{ string foo(string a){ return a; } } void main(){ writeln(foo(2)); writeln(foo(a)); writeln(g.foo(2));

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. There is no need to add namespaces to do that, and if that's really what you want it belongs in a completely

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 10:32 PM, Daniel N wrote: The disadvantage of this is that it forces one .di file per namespace, whereas in C++ people frequently use different namespaces within the same file. Andrei I would argue that this restriction is a benefit not a disadvantage, Why on earth would

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/26/2014 09:56 PM, Andrei Alexandrescu wrote: I think this is not a good proposal from a proportional response standpoint: it squanders a keyword for a minor feature. I also think the preexisting suggestions are each wanting in various ways. That's why we should guide the discussion not

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 12:03 AM, David Nadlinger wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: Which is all the DIP adds. I do not really understand the objections. It adds a new language feature, which is not just used only in a rather specific situation, but also very likely

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 12:43 AM, Dicebot wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage conflicts and organisation in D code - modules! Named mixin templates are a much closer fit. Using named

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 01:11 AM, Dicebot wrote: On Saturday, 26 April 2014 at 23:05:23 UTC, Timon Gehr wrote: On 04/27/2014 12:43 AM, Dicebot wrote: On Saturday, 26 April 2014 at 21:57:55 UTC, Timon Gehr wrote: On 04/26/2014 09:27 PM, Daniel Murphy wrote: We already have a feature to manage

Re: DIP60: @nogc attribute

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 01:32 AM, bearophile wrote: If I am not missing some more point, what is the best solution? Before this question gets lost, I'd like to receive some kind of answer. Thank you, bearophile The front end already distinguishes dynamic and static array literals (in a limited

Re: possible bug in std.conv.parse

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 01:43 AM, Adam D. Ruppe wrote: On Saturday, 26 April 2014 at 23:36:28 UTC, ketmar wrote: this code: std.conv.parse!byte(-128) throws error: Overflow in integral conversion. but this is obviously not true, as signed byte can hold such value. Check your math... the most negative

Re: DIP61: Add namespaces to D

2014-04-26 Thread Timon Gehr via Digitalmars-d
On 04/27/2014 01:59 AM, Andrei Alexandrescu wrote: On 4/26/14, 4:32 PM, Walter Bright wrote: Since the namespace keyword doesn't seem to be gaining much traction, an alternative syntax would be: extern (C++, N.M) { void foo(); } which would be semantically equivalent to the previous:

Re: DIP61: redone to do extern(C++,N) syntax

2014-04-29 Thread Timon Gehr via Digitalmars-d
On 04/29/2014 01:34 PM, Simen Kjærås via Digitalmars-d wrote: Building on this knowledge: module foo; void func(); module bar; extern(C++, foo) void func(); module prog; import foo; import bar; void main() { // Seems like it's ambiguous between foo.func and bar.foo.func.

Re: DIP61: redone to do extern(C++,N) syntax

2014-04-29 Thread Timon Gehr via Digitalmars-d
On 04/29/2014 02:01 PM, Steven Schveighoffer wrote: That is what the DIP says: Declarations in the namespace can be accessed without qualification in the enclosing scope if there is no ambiguity. Ambiguity issues can be resolved by adding the namespace qualifier Which then proceeds to show

Re: DIP61: redone to do extern(C++,N) syntax

2014-04-29 Thread Timon Gehr via Digitalmars-d
On 04/29/2014 05:52 PM, Steven Schveighoffer wrote: I am not familiar with the rules. Perhaps you can just outline for me: module bar; extern(C++, foo) void func(); module prog; import bar; void main() { foo.func(); // works? } If this works, then we have a problem. It does work.

Re: DIP61: redone to do extern(C++,N) syntax

2014-04-29 Thread Timon Gehr via Digitalmars-d
On 04/29/2014 10:49 PM, Steven Schveighoffer wrote: On Tue, 29 Apr 2014 16:00:43 -0400, Steven Schveighoffer schvei...@yahoo.com wrote: On Tue, 29 Apr 2014 15:52:01 -0400, Walter Bright newshou...@digitalmars.com wrote: Because the compiler would now issue an error for that, it's its

Re: DIP61: redone to do extern(C++,N) syntax

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 02:41 AM, Steven Schveighoffer wrote: On Tue, 29 Apr 2014 17:38:07 -0400, Timon Gehr timon.g...@gmx.ch wrote: ... Maybe he didn't notice that you changed the 'main' function relative to my post. If you don't mention 'foo' explicitly, then obviously it cannot be hidden by the

Re: D vs Rust: function signatures

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 04:04 AM, Vladimir Panteleev wrote: fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self Same as points 1 and 3 above (D's version allows specifying multiple functions). Not sure what 'r or |A| means in Rust syntax, but I guess this would be the equivalent D syntax: auto

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 10:45 PM, Andrei Alexandrescu wrote: An extreme one indeed, it would break a lot of my code. Every D project I wrote that does networking manages memory using a class that resides on the managed heap, but holds the actual wrapped data in the unmanaged heap. So should I take it

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 10:21 PM, Andrei Alexandrescu wrote: Walter and I have had a long chat in which we figured our current offering of abstractions could be improved. Here are some thoughts. There's a lot of work ahead of us on that and I wanted to make sure we're getting full community buy-in and

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 10:58 PM, Andrei Alexandrescu wrote: On 4/30/14, 1:56 PM, Timon Gehr wrote: struct S{ ~this(){ /* ... */ } /* ... */ } class C{ S s; } ? By hand, as I mentioned. -- Andrei I meant, is it going to be deprecated too?

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 04/30/2014 10:57 PM, Andrei Alexandrescu wrote: RCSlice!(const T) has nothing to do with const(RCSlice!T) as far as the compiler is concerned. ... There's always this hack: struct RCSlice(T){ static if(!is(T==const)) RCSlice!(const(StripImmutable!T)) upcast(){

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 05/01/2014 12:24 AM, Timon Gehr wrote: I think this fixes the issue in general, for example, for ranges: const rng1 = [1,2,3].map!(a=2*a); const rng2 = rng1.filter!(a=!!(a1)); // ok Probably this should be slightly generalized, eg: ... (The generalization is actually needed for the

Re: More radical ideas about gc and reference counting

2014-04-30 Thread Timon Gehr via Digitalmars-d
On 05/01/2014 12:24 AM, Timon Gehr wrote: const(Slice!C) cs=s; // ok, D* coercible to n-m-ind const(C*) sc=cs; // ok, D* is coercible to n-m-ind const(C)* (Ignore the 'n-m-ind', those are accidental leftovers from a half-baked version of the post.)

Re: More radical ideas about gc and reference counting

2014-05-01 Thread Timon Gehr via Digitalmars-d
On 05/01/2014 12:48 AM, deadalnix wrote: On Wednesday, 30 April 2014 at 22:24:29 UTC, Timon Gehr wrote: However, then, whether to do const(S!T) = S!(const(T)) or const(S!T) = S!(TailConst!T) should maybe be specified on a per-parameter basis, because this is in general not easy to figure out

Re: Scenario: OpenSSL in D language, pros/cons

2014-05-06 Thread Timon Gehr via Digitalmars-d
On 05/05/2014 12:41 PM, Jonathan M Davis via Digitalmars-d wrote: Regardless, there's nothing fundamentally limited about @safe except for operations which are actually unsafe with regards to memory What does 'actually unsafe' mean? @safe will happily ban statements that will never 'actually'

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 05:58 AM, Andrei Alexandrescu wrote: ... import std.stdio; void fun(T)(T x) { writeln(typeof(x).stringof); } void main() { immutable(int[]) a = [ 1, 2 ]; writeln(typeof(a).stringof); fun(a); } This program outputs: immutable(int[]) immutable(int)[] which means

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 08:55 AM, Jonathan M Davis via Digitalmars-d wrote: As far as I can see, opByValue does the same thing as opSlice, except that it's used specifically when passing to functions, whereas this code immutable int [] a = [1, 2, 3]; immutable(int)[] b = a[]; or even immutable int [] a

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 12:14 PM, Michel Fortin wrote: Will this solve the problem that const(MyRange!(const T)) is a different type from const(MyRange!(T))? No, but as stated it aggravates this problem. I doubt it. But they should be the same type if we want to follow the semantics of the language's

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 09:01 AM, Jonathan M Davis via Digitalmars-d wrote: It really has nothing to do with passing an argument to a function beyond the fact that that triggers an implicit call to the slice operator. module check_claim; import std.stdio; auto foo(immutable(int)[] a){writeln(Indeed,

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 01:05 PM, monarch_dodra wrote: ... In fact, I'm wondering if this might not be a more interesting direction to explore. http://forum.dlang.org/thread/ljrm0d$28vf$1...@digitalmars.com?page=3#post-ljrt6t:242fpc:241:40digitalmars.com

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 06:02 PM, monarch_dodra wrote: If you have const data referencing mutable data, then yes, you can cast away all the const you want, but at that point, it kind of makes the whole const thing moot. This is not guaranteed to work. I guess the only related thing that is safe to do

Re: From slices to perfect imitators: opByValue

2014-05-08 Thread Timon Gehr via Digitalmars-d
On 05/08/2014 06:30 PM, Sönke Ludwig wrote: Am 08.05.2014 18:10, schrieb Timon Gehr: On 05/08/2014 06:02 PM, monarch_dodra wrote: If you have const data referencing mutable data, then yes, you can cast away all the const you want, but at that point, it kind of makes the whole const thing

Re: More radical ideas about gc and reference counting

2014-05-11 Thread Timon Gehr via Digitalmars-d
On 05/11/2014 10:29 AM, Walter Bright wrote: ... - A Comment on Rust -- This is based on my very incomplete knowledge of Rust, i.e. just reading a few online documents on it. If I'm wrong, please correct me. ... Well, region-based memory management is not new, and

Re: More radical ideas about gc and reference counting

2014-05-11 Thread Timon Gehr via Digitalmars-d
On 05/11/2014 10:05 PM, Walter Bright wrote: On 5/11/2014 8:54 AM, Timon Gehr wrote: It is not an escape from ARC per se. It is a way to write type safe code which is not dependent on the allocation strategy of the processed data. (One can e.g. safely borrow mutable data as immutable and the

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 02:50 AM, Walter Bright wrote: On 5/11/2014 1:59 PM, Timon Gehr wrote: On 05/11/2014 10:05 PM, Walter Bright wrote: That's clearly an additional benefit of the borrowed pointer notion. But have you examined generated Rust code for the cost of inc/dec? I haven't, but I don't see

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 10:54 AM, Walter Bright wrote: On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright newshou...@digitalmars.com: As long as those pointers don't escape. Am I right in that one cannot store a borrowed pointer into a global data

Re: More radical ideas about gc and reference counting

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 06:37 PM, Walter Bright wrote: On 5/12/2014 5:15 AM, Timon Gehr wrote: On 05/12/2014 10:54 AM, Walter Bright wrote: On 5/11/2014 10:57 PM, Marco Leise wrote: Am Sun, 11 May 2014 17:50:25 -0700 schrieb Walter Bright newshou...@digitalmars.com: As long as those pointers don't

Re: borrowed pointers vs ref

2014-05-12 Thread Timon Gehr via Digitalmars-d
On 05/12/2014 10:36 PM, Walter Bright wrote: It's been brought up more than once that the 'scope' storage class is an unimplemented borrowed pointer. But thinking a bit more along those lines, actually 'ref' fills the role of a borrowed pointer. One particularly apropos behavior is that

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Timon Gehr via Digitalmars-d
On 05/13/2014 03:56 PM, Dicebot wrote: On Monday, 12 May 2014 at 19:32:49 UTC, Jacob Carlborg wrote: On 2014-05-12 19:14, Dicebot wrote: It lacks any good static reflection though. And this stuff is damn addictive when you try it of D caliber. It has macros, that basically requires great

Re: Next step on reference counting topics

2014-05-13 Thread Timon Gehr via Digitalmars-d
On 05/13/2014 05:11 PM, Andrei Alexandrescu wrote: On 5/13/14, 6:41 AM, Dicebot wrote: On Monday, 12 May 2014 at 19:00:33 UTC, Andrei Alexandrescu wrote: For that I'm proposing we start real work toward a state-of-the-art std.refcounted module. It would include adapters for class, array, and

Re: More radical ideas about gc and reference counting

2014-05-13 Thread Timon Gehr via Digitalmars-d
On 05/13/2014 09:07 PM, Jacob Carlborg wrote: On 2014-05-13 15:56, Dicebot wrote: Judging by http://static.rust-lang.org/doc/0.6/tutorial-macros.html those are not full-blown AST macros like ones you have been proposing, more like hygienic version of C macros. Hmm, I haven't looked at Rust

Re: More radical ideas about gc and reference counting

2014-05-14 Thread Timon Gehr via Digitalmars-d
On 05/14/2014 06:41 PM, Wyatt wrote: To me, shared is a type modifier that doesn't implicitely convert to anything else without casting. Interesting, maybe this should be clarified better. Having skimmed back over chapter 13 of TDPL, my understanding of its semantics are that it only really

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 02:57 PM, Steven Schveighoffer wrote: On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote: A little example of D purity (this compiles): bool randomBit() pure nothrow

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 05:24 PM, Andrei Alexandrescu wrote: On 5/15/14, 3:31 AM, luka8088 wrote: Yeah, I read all about weak/string purity and I do understand the background. I was talking about strong purity, maybe I should pointed that out. So, to correct myself: As I understood strong purity implies

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 11:45 AM, Don wrote: No global state is a deep, transitive property of a function. Memoizable is a superficial supersetextra Why? A memoizable function is still memoizable if it is changed internally to memoize values in global memory, for example. property which the

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 07:41 PM, Steven Schveighoffer wrote: Not really, allocation is just an implementation detail. The computational language is meaningful independent of how you might achieve evaluation of expressions. I can in principle evaluate an expression of such a language on paper without

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 11:33 PM, Walter Bright wrote: On 5/15/2014 9:07 AM, Timon Gehr wrote: Why? A memoizable function is still memoizable if it is changed internally to memoize values in global memory, for example. I doubt a compiler could prove it was pure. Yes, that was actually my point.

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 03:06 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 15 May 2014 at 12:37:22 UTC, w0rp wrote: To consider the design of pure, you must first consider that you cannot add functional purity to an imperative language. Of course you can. Functional

Re: Memory allocation purity

2014-05-15 Thread Timon Gehr via Digitalmars-d
On 05/15/2014 08:03 PM, Andrei Alexandrescu wrote: Purity of allocation is frequently assumed by functional languages Examples? cons 1 2 is equal to cons 1 2 ... I don't see anything whose specification would need to mention 'allocation'. because without it it would be difficult to get

Re: Memory allocation purity

2014-05-16 Thread Timon Gehr via Digitalmars-d
On 05/16/2014 01:00 AM, H. S. Teoh via Digitalmars-d wrote: On Thu, May 15, 2014 at 03:22:25PM -0700, Walter Bright via Digitalmars-d wrote: On 5/15/2014 2:41 PM, Timon Gehr wrote: On 05/15/2014 11:33 PM, Walter Bright wrote: On 5/15/2014 9:07 AM, Timon Gehr wrote: Why? A memoizable function

Re: Memory allocation purity

2014-05-16 Thread Timon Gehr via Digitalmars-d
On 05/16/2014 01:56 AM, Walter Bright wrote: On 5/15/2014 4:00 PM, H. S. Teoh via Digitalmars-d wrote: What if the language allowed the user to supply a proof of purity, which can be mechanically checked? I think those sorts of things are PhD research topics. Well, feasibility has long ago

Re: Memory allocation purity

2014-05-17 Thread Timon Gehr via Digitalmars-d
On 05/16/2014 07:41 PM, Andrei Alexandrescu wrote: On 5/16/14, 4:53 AM, Timon Gehr wrote: ... Yes, either that or one could even just implement it in the existing language by introducing types for evidence, and basic termination checking. eg. http://dpaste.dzfl.pl/33018edab028 On 5/16/14,

Re: Memory allocation purity

2014-05-17 Thread Timon Gehr via Digitalmars-d
On 05/17/2014 09:29 PM, Timon Gehr wrote: Typo: int_leibiz_equality :o). -- Andrei If that is everything, then I am in good shape! :o) It could be argued though, that this axiom was not too aptly named in the first place, because it describes the indiscernibility of identicals instead

Re: Memory allocation purity

2014-05-19 Thread Timon Gehr via Digitalmars-d
On 05/19/2014 09:03 PM, Dicebot wrote: immutable(Object*) alloc() pure { return new Object(); } bool oops() pure { auto a = alloc(); auto b = alloc(); return a is b; } This is a snippet that will always return `true` if memoization is at work and `false` if strongly pure

Re: To deadalnix

2014-05-24 Thread Timon Gehr via Digitalmars-d
On 05/24/2014 05:03 AM, Joshua Niehus wrote: watching your talk was like witnessing Fermats last theorem being proven... the scheduler solution was brilliant and the semantic analysis of a mixin statement that resulted in a comprehensible error message blew my mind. Here is a belated applause

Re: Ref counting for CTFE?

2014-05-29 Thread Timon Gehr via Digitalmars-d
On 05/29/2014 07:33 PM, Steven Schveighoffer wrote: But CTFE is full of code that expects to have a GC running, e.g. string concatenation for mixins, etc. Even the following code runs out of memory on my machine: int foo(){ foreach(i;0..1){} return 2; } pragma(msg, foo());

Re: Ref counting for CTFE?

2014-05-29 Thread Timon Gehr via Digitalmars-d
On 05/29/2014 06:53 PM, Dylan Knutson wrote: ... Is there anything so radically different in D than these other languages, that prevents the implementation of a run-of-the-mill VM to eval D code? No. (In fact, I've written a naive but mostly complete byte code interpreter in half a week or

Re: [OT] Apple introduces Swift as Objective-C sucessor

2014-06-02 Thread Timon Gehr via Digitalmars-d
On 06/02/2014 11:15 PM, Steven Schveighoffer wrote: They have template constraints similar to D. It looks something like this: func fooT where T == Int(t: T) I think everything after the where can be some condition, but I don't know how expressive that is. The examples aren't very telling.

Re: [OT] Apple introduces Swift as Objective-C sucessor

2014-06-02 Thread Timon Gehr via Digitalmars-d
On 06/02/2014 10:23 PM, Nick Sabalausky wrote: On 6/2/2014 3:49 PM, Steven Schveighoffer wrote: On Mon, 02 Jun 2014 15:45:28 -0400, Paulo Pinto pj...@progtools.org wrote: More information now made available https://developer.apple.com/swift/ Memory is managed automatically, and you don’t

Re: @safe inference fundamentally broken

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/05/2014 08:09 PM, Steven Schveighoffer wrote: A quick example: T[] getBuf(T)() @safe { T[100] ret; auto r = ret[]; return r; } void main() @safe { auto buf = getBuf!int(); } Note, the above compiles. An interesting thing here is that we have explicitly marked getBuf as

Re: @safe inference fundamentally broken

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/05/2014 08:17 PM, deadalnix wrote: @safe is fundamentally broken. What's the fundamental problem? The construct seems perfectly fit to specify memory safety in at least the following context: void main()@safe{} :o)

Re: @safe inference fundamentally broken

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/05/2014 08:47 PM, deadalnix wrote: On Thursday, 5 June 2014 at 18:33:22 UTC, Timon Gehr wrote: On 06/05/2014 08:17 PM, deadalnix wrote: @safe is fundamentally broken. What's the fundamental problem? The construct seems perfectly fit to specify memory safety in at least the following

Re: @safe inference fundamentally broken

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/05/2014 08:35 PM, Steven Schveighoffer wrote: On Thu, 05 Jun 2014 14:30:49 -0400, Timon Gehr timon.g...@gmx.ch wrote: The fundamental issue seems to lie in methodology and it is that @safe is approximated by the DMD implementation from the wrong side. Instead of gradually banning usage

Re: Is Bug 5710 likely to get fixed?

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/05/2014 08:42 PM, Steven Schveighoffer wrote: On Thu, 05 Jun 2014 14:16:06 -0400, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: https://issues.dlang.org/show_bug.cgi?id=5710 Is this likely to get fixed or is it more likely to drift along as an unfixed issue? If

Re: @safe inference fundamentally broken

2014-06-05 Thread Timon Gehr via Digitalmars-d
On 06/06/2014 01:15 AM, Walter Bright wrote: On 6/5/2014 11:09 AM, Steven Schveighoffer wrote: Thoughts? Please file bugzilla issue(s) for this. There already is one: https://issues.dlang.org/show_bug.cgi?id=8838

Re: [OT] Extra time spent

2014-06-06 Thread Timon Gehr via Digitalmars-d
On 06/06/2014 04:37 PM, H. S. Teoh via Digitalmars-d wrote: Yeah that sounds very familiar. A typical situation at my job goes something like this: Customer: I want feature X! Sales rep: OK, we'll implement X in 1 month. Customer: No, I want it by last month! Sales rep: OK, and we'll throw in

Re: How to best translate this C++ algorithm into D?

2014-06-07 Thread Timon Gehr via Digitalmars-d
On 06/07/2014 05:50 AM, logicchains wrote: While my (much more concise; thanks D!) attempt at implementing it is: forest_t[] meal(in forest_t[] forests) { forest_t[3] possible_meals = [{-1, -1, +1}, {-1, +1, -1}, {+1, -1, -1}]; return map!(a = [possible_meals[0]+a, possible_meals[1]+a,

Re: How to best translate this C++ algorithm into D?

2014-06-07 Thread Timon Gehr via Digitalmars-d
On 06/07/2014 03:04 PM, logicchains wrote: ... return map!(a = [forest_t(-1, -1, +1)+a, forest_t(-1, +1, -1)+a, forest_t(+1, -1, -1)+a])(forests) .join .partition!(forest_invalid) .sort.uniq.array; What about (untested)?: static forest_t[] possible_meals = [{-1, -1, +1}, {-1, +1,

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-11 Thread Timon Gehr via Digitalmars-d
On 06/11/2014 11:35 AM, Walter Bright wrote: I'm not so sure about that, either. There are many ways of bit copying structs, and some of them are perfectly memory safe. It is not provable by the compiler, therefore it is not @safe. Not memory safe implies (is supposed to imply) not @safe

Re: foreach

2014-06-12 Thread Timon Gehr via Digitalmars-d
On 06/12/2014 10:06 PM, Steven Schveighoffer wrote: I don't think it's as trivial as you imply. You have to use a symbol that's valid, but isn't used in the subsequent loop to avoid collisions. -Steve Why would implicit local variables need unique names? This can be implemented by

Re: foreach

2014-06-13 Thread Timon Gehr via Digitalmars-d
On 06/12/2014 06:59 PM, bearophile wrote: Nick Treleaven: there is also this usage: foreach (i, _; range){...} I think this is a very uncommon usage. I think I have not used it so far. Have you ever used void[0][T]?

Re: foreach

2014-06-13 Thread Timon Gehr via Digitalmars-d
On 06/13/2014 01:55 PM, Dicebot wrote: Over 50 comments about minor syntax issue ... Including yours.

Re: foreach

2014-06-13 Thread Timon Gehr via Digitalmars-d
On 06/13/2014 07:39 PM, Meta wrote: On Friday, 13 June 2014 at 17:05:26 UTC, H. S. Teoh via Digitalmars-d wrote: I don't like arbitrary constants like the `true` in while(true) -- it kinda goes against the grain, that while implies there is a stopping point, but sticking true in there

Re: Null pointer dereferencing in D

2014-06-13 Thread Timon Gehr via Digitalmars-d
On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote: On Fri, 13 Jun 2014 21:23:00 + deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: The approach consisting in having non nullable pointers/reference by default is the one that is gaining traction and for good

Re: foreach

2014-06-14 Thread Timon Gehr via Digitalmars-d
On 06/13/2014 11:41 PM, Jonathan M Davis via Digitalmars-d wrote: It's a special case in that the middle portion is supposed to be the condition that the loop use to determine whether it can continue, and omitting it means that it has to add the true itself, No, omitting it means that it does

Re: Null pointer dereferencing in D

2014-06-14 Thread Timon Gehr via Digitalmars-d
On 06/14/2014 02:39 AM, Jonathan M Davis via Digitalmars-d wrote: On Sat, 14 Jun 2014 00:34:51 +0200 Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote: On 06/13/2014 11:45 PM, Jonathan M Davis via Digitalmars-d wrote: On Fri, 13 Jun 2014 21:23:00 + deadalnix via Digitalmars-d

Re: foreach

2014-06-14 Thread Timon Gehr via Digitalmars-d
On 06/14/2014 05:33 PM, bearophile wrote: Timon Gehr: Have you ever used void[0][T]? I have never used that so far. What is it useful for? Bye, bearophile It's a hash set with a somewhat awkward interface.

Re: foreach

2014-06-14 Thread Timon Gehr via Digitalmars-d
On 06/14/2014 11:23 PM, Jonathan M Davis via Digitalmars-d wrote: ... It's the lack of a condition that I object to. IMHO it's a fundamental violation of how loops work. Fundamentally, loops loop. That is the only fundamental thing about loops.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d
On 06/15/2014 10:33 AM, Walter Bright wrote: What Timon is saying is that not all memory safe code is verifiably @safe. In D, they are defined to be the same thing, Since when? http://dlang.org/function Function Safety Safe functions are functions that are _statically checked_ to exhibit

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d
On 06/15/2014 08:44 PM, Walter Bright wrote: On 6/15/2014 2:48 AM, Timon Gehr wrote: On 06/15/2014 10:33 AM, Walter Bright wrote: What Timon is saying is that not all memory safe code is verifiably @safe. In D, they are defined to be the same thing, Since when? http://dlang.org/function

Re: DIP63 : operator overloading for raw templates

2014-06-15 Thread Timon Gehr via Digitalmars-d
On 06/15/2014 08:32 PM, Dicebot wrote: http://wiki.dlang.org/DIP63 This is solution for a problem I am currently having with implementing http://wiki.dlang.org/DIP54 (afair it was also mentioned by Timon Gehr during old discussion of that DIP) New proposed semantics ( to catch your attention

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-15 Thread Timon Gehr via Digitalmars-d
On 06/16/2014 01:06 AM, Walter Bright wrote: On 6/15/2014 3:45 PM, Timon Gehr wrote: I don't know why the documentation says that. D's @safe is about memory safety, not undefined behavior. ... Note that this is frustratingly unhelpful for deciphering your point about memory safe = verifiably

Re: A Perspective on D from game industry

2014-06-16 Thread Timon Gehr via Digitalmars-d
On 06/16/2014 03:12 AM, H. S. Teoh via Digitalmars-d wrote: This insight therefore causes D's templates to mesh very nicely with CTFE to form a beautifully-integrated whole. I wouldn't go exactly that far. For one thing, CTFE cannot be used to manipulate types.

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-16 Thread Timon Gehr via Digitalmars-d
On 06/16/2014 06:49 AM, Walter Bright wrote: On 6/15/2014 4:26 PM, Timon Gehr wrote: On 06/16/2014 01:06 AM, Walter Bright wrote: I don't understand your question. I don't know what is unhelpful about saying that @safe refers to memory safety. ... You stated the two to be equivalent earlier,

Re: A Perspective on D from game industry

2014-06-16 Thread Timon Gehr via Digitalmars-d
On 06/16/2014 05:18 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Monday, 16 June 2014 at 15:07:08 UTC, H. S. Teoh via Digitalmars-d wrote: Having said that, though, proper use of string mixins with CTFE and templates ('scuse me, *compile-time arguments* ;)) can be

Re: Not initialized out argument error

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 02:02 AM, Walter Bright wrote: On 6/16/2014 3:51 PM, bearophile wrote: test.d(1,21): Error: uninitialised out argument of 'test3.foo' function But it is not uninitialized. All out parameters are default initialized to their .init value. struct S{ @disable this(); } void

Re: A Perspective on D from game industry

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 04:00 PM, John Colvin wrote: I though the primary use of static foreach was to force the compiler to attempt compile-time iteration even for non-TemplateArgList arguments like arrays known at compile-time e.g. static foreach(el; [1,2,3,4]) { pragma(msg, el); } or static

Re: A Perspective on D from game industry

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 03:36 PM, John Colvin wrote: also, foreach that works outside of function scope would be awesome: mixin template A(TL ...) { foreach(i, T; TL) { mixin(T v ~ i.to!string); } } Also, identifier mixins might then somewhat clean up a lot of code. The

Re: A Perspective on D from game industry

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 01:16 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 17 June 2014 at 09:17:21 UTC, Nick Sabalausky wrote: I think you're hitting on the fundamental limitations of automated code-updating tools here: They can't be treated as trusted black-boxes. I

Re: A Perspective on D from game industry

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 06:53 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Tuesday, 17 June 2014 at 16:34:23 UTC, Timon Gehr wrote: On 06/17/2014 01:16 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: Programming languages are in general still quite primitive

Re: Tail pad optimization, cache friendlyness and C++ interrop

2014-06-17 Thread Timon Gehr via Digitalmars-d
On 06/17/2014 11:50 PM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: ... Btw, Rice's theorem is based on the halting problem for TMs… so it suffers from the same issues as everything else in theoretical CS when it comes to practical situations. There is no such 'issue', or

Re: RFC: Value range propagation for if-else

2014-06-19 Thread Timon Gehr via Digitalmars-d
On 06/18/2014 09:54 PM, Meta wrote: ... This could be a bad thing. It makes it pretty enticing to use contracts as input verification instead of logic verification. The following is doable as well with a standard range analysis: byte foo(immutable int x){ if(xbyte.min || xbyte.max)

Re: Adding the ?. null verification

2014-06-19 Thread Timon Gehr via Digitalmars-d
On 06/18/2014 09:36 PM, H. S. Teoh via Digitalmars-d wrote: Here's a first stab at a library solution: /** * Simple-minded implementation of a Maybe monad. * Nitpick: Please do not call it a 'Maybe monad'. It is not a monad: It's neither a functor not does it have a

Re: Adding the ?. null verification

2014-06-19 Thread Timon Gehr via Digitalmars-d
On 06/19/2014 06:58 PM, Yota wrote: Won't opDispatch here destroy any hope for statement completion in the future? I feel like D already has little hope for such tooling features, but this puts the final nail in the coffin. auto opDispatch(string field)() if(is(typeof(__traits(getMember,

  1   2   3   4   5   6   7   8   9   10   >