Re: DIP 88: Simple form of named parameters

On 2016-01-23 14:19:03 +, Jacob Carlborg said: This is mostly to prevent ugly hacks like Flag [1]. http://wiki.dlang.org/DIP88 [1] https://dlang.org/phobos/std_typecons.html#.Flag On further thought, how do you make templates with specialization take named arguments?

Re: DIP 88: Simple form of named parameters

On 2016-01-23 14:19:03 +, Jacob Carlborg said: This is mostly to prevent ugly hacks like Flag [1]. http://wiki.dlang.org/DIP88 [1] https://dlang.org/phobos/std_typecons.html#.Flag Interesting. This is somewhat similar to an experiment of mine from 5 years ago. My

Re: OT: Swift is now open source

On 2015-12-06 10:43:24 +, Jacob Carlborg said: You're decoding characters (grapheme clusters) as you advance those indexes. Not really what I needed, for me it would be enough with slicing the bytes. That only works if the actual underlying representation is UTF8 (or

Re: OT: Swift is now open source

On 2015-12-04 07:51:32 +, Jacob Carlborg said: On 2015-12-03 20:10, Steven Schveighoffer wrote: The truth is, swift is orders of magnitude better than Objective C. I have gotten used to the nullable API, though it sometimes seems more clunky than useful. I find it very

Re: Firs step of D/Objective-C merged

On 2015-07-14 18:53:31 +, Jacob Carlborg d...@me.com said: Hmm, I see. I imagined something similar would need to be done for the new exception handling in Swift 2, but for every method, that was unexpected. Now when Swift goes open source someone can just have a look and see what's going

Re: Firs step of D/Objective-C merged

On 2015-07-14 13:59:51 +, Jacob Carlborg d...@me.com said: On 2015-07-14 03:11, Michel Fortin wrote: More or less. If you define an `extern (Objective-C)` class in D (once all my work is merged), you can use it and derive from it in Swift. If you define an `@objc` class in Swift you can

Re: Firs step of D/Objective-C merged

On 2015-07-13 14:02:54 +, Steven Schveighoffer schvei...@yahoo.com said: I wanted to ask, swift can call into objective-C, so does this de-facto give us a D/swift binding as well? I haven't written a single line of swift yet, so apologies if this is a stupid question. More or less. If

Re: As discussed in DConf2015: Python-like keyword arguments

On 2015-05-31 04:08:33 +, ketmar ket...@ketmar.no-ip.org said: my work now allows this: string test (string a, string b=3Dwow, string c=3Dheh) { return a~b~c; } void main () { enum str =3D test(c: cc, a: aa); assert(str =3D=3D aawowcc); } How does it handle

Re: As discussed in DConf2015: Python-like keyword arguments

On 2015-05-29 12:27:02 +, Jacob Carlborg d...@me.com said: And here's an implementation with language support which allows named arguments but not reordering the arguments [2]. Originally implemented by Michel Fortin. [2] https://github.com/jacob-carlborg/dmd/tree/named_parameters I

Re: A few thoughts on std.allocator

On 2015-05-12 17:21:03 +, Steven Schveighoffer schvei...@yahoo.com said: Of course, array appending is an odd duck here, as generally you are not generally able to add data to an immutable piece of data. A similar odd duck would be reference counting (again, mutable metadata attached to

Re: A few thoughts on std.allocator

On 2015-05-10 09:50:00 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: 3. Thread-local vs. shared objects Currently in D it's legal to allocate memory in one thread and deallocate it in another. (One simple way to look at it is casting to shared.) This has a large performance

Re: std.xml2 (collecting features)

On 2015-05-03 17:39:46 +, Robert burner Schadek rburn...@gmail.com said: std.xml has been considered not up to specs nearly 3 years now. Time to build a successor. I currently plan the following featues for it: - SAX and DOM parser - in-situ / slicing parsing when possible (forward

Re: C++/C mangleof inconsistency for OS X

On 2015-04-22 16:32:55 +, Dan Olson zans.is.for.c...@yahoo.com said: Since the compile chain knows whether the target system prepends an underscore, I wonder if it can be bubbled up into some compiler trait or version that prevents writing versioned code based on system. I think it would

Re: C++/C mangleof inconsistency for OS X

On 2015-04-21 18:29:36 +, Jacob Carlborg d...@me.com said: On 2015-04-21 19:01, Dan Olson wrote: If I want to call a C function void debug(const char*) from a C library, I would do this because of D debug keyword: pragma(mangle, debug) extern (C) void debug_c(const(char*)); Now I

Re: C++/C mangleof inconsistency for OS X

On 2015-04-21 17:01:51 +, Dan Olson zans.is.for.c...@yahoo.com said: Dan Olson zans.is.for.c...@yahoo.com writes: Jacob Carlborg d...@me.com writes: On 2015-04-20 18:33, Dan Olson wrote: An observation on OSX w/ 2.067: mangleof for C++ (and D) names produces the actual object file

Re: Any D plugins for recent Xcode?

On 2015-04-19 00:28:14 +, Michel Fortin michel.for...@michelf.ca said: On 2015-04-18 20:18:56 +, Dan Olson zans.is.for.c...@yahoo.com said: Yeah, I was hoping somone might have done the same for Xcode 6. I've never poked at how Xcode plugins works, maybe somehow it can be upgraded.

Re: Any D plugins for recent Xcode?

On 2015-04-18 20:18:56 +, Dan Olson zans.is.for.c...@yahoo.com said: Yeah, I was hoping somone might have done the same for Xcode 6. I've never poked at how Xcode plugins works, maybe somehow it can be upgraded. I have gotten the impression that the Xcode plugin API changes often and is

Re: SDC needs you

On 2015-04-17 02:19:49 +, Walter Bright newshou...@digitalmars.com said: On 4/16/2015 10:47 AM, Michel Fortin wrote: It would be sad to see all those efforts wasted. Yes it would. The problem is I have a hard time reviewing complex things I don't understand, so I procrastinate. The

Re: SDC needs you

On 2015-04-16 06:50:35 +, Jacob Carlborg d...@me.com said: I've been working on the Objective-C support for quite a while. I'm on my third rewrite due to comments in previous pull requests. The latest pull request [1] was created in January, it's basically been stalled since February due

Re: DIP77 - Fix unsafe RC pass by 'ref'

On 2015-04-10 21:29:19 +, Walter Bright newshou...@digitalmars.com said: On 4/10/2015 2:11 PM, Martin Nowak wrote: On 04/09/2015 01:10 AM, Walter Bright wrote: http://wiki.dlang.org/DIP77 In the first problem example: struct S { RCArray!T array; } void main() { auto s

Re: DIP77 - Fix unsafe RC pass by 'ref'

On 2015-04-10 23:22:17 +, deadalnix deadal...@gmail.com said: On Friday, 10 April 2015 at 23:18:59 UTC, Martin Nowak wrote: On 04/10/2015 11:29 PM, Walter Bright wrote: The latter. Can you update that part in the DIP, it wasn't clear that the temporary selectively pins RCO fields of a

Re: DIP77 - Fix unsafe RC pass by 'ref'

On 2015-04-08 23:10:37 +, Walter Bright newshou...@digitalmars.com said: http://wiki.dlang.org/DIP77 In the definition of a Reference Counted Object: An object is assumed to be reference counted if it has a postblit and a destructor, and does not have an opAssign marked @system. Why

Re: RCArray is unsafe

On 2015-03-02 05:57:12 +, Walter Bright said: On 3/1/2015 12:51 PM, Michel Fortin wrote: That's actually not enough. You'll have to block access to global variables too: Hmm. That's not so easy to solve. Let's see. The problem is that 'ref' variables get invalidated by some

Re: RCArray is unsafe

On 2015-03-03 22:39:12 +, Michel Fortin said: Let's see. The problem is that 'ref' variables get invalidated by some operations. Perhaps we could just tell the compiler that doing this or that will makes 'ref' variables unsafe after that point. Let's try adding a @refbreaking function

Re: Making RCSlice and DIP74 work with const and immutable

On 2015-03-01 01:40:42 +, Andrei Alexandrescu said: Tracing garbage collection can afford the luxury of e.g. mutating data that was immutable during its lifetime. Reference counting needs to make minute mutations to data while references to that data are created. In fact, it's not

Re: RCArray is unsafe

On 2015-03-01 19:21:57 +, Walter Bright said: The trouble seems to happen when there are two references to the same object passed to a function. I.e. there can be only one borrowed ref at a time. I'm thinking this could be statically disallowed in @safe code. That's actually not

Re: Improving DIP74: functions borrow by default, retain only if needed

On 2015-02-27 23:11:55 +, deadalnix said: On Friday, 27 February 2015 at 23:06:26 UTC, Andrei Alexandrescu wrote: OK, so at least in theory autorelease pools are not necessary for getting ARC to work? -- Andrei ARC need them, this is part of the spec. You can have good RC without them

Re: Improving DIP74: functions borrow by default, retain only if needed

On 2015-02-27 20:34:08 +, Steven Schveighoffer said: On 2/27/15 3:30 PM, Steven Schveighoffer wrote: void main() { C c = new C; // ref counted class C2 c2 = new C2; // another ref counted class c2.c = c; foo(c, c2); } Bleh, that was dumb. void main() { C2 c2 = new C2; c2.c =

Re: Improving DIP74: functions borrow by default, retain only if needed

On 2015-02-27 21:33:51 +, Steven Schveighoffer said: I believe autorelease pools are not needed for ARC, but are maintained because much Objective-C code contains MRC, and that protocol needs to be supported. Exactly. -- Michel Fortin michel.for...@michelf.com http://michelf.com/

Re: A Refcounted Array Type

On 2015-02-26 21:07:26 +, Andrei Alexandrescu said: On 2/26/15 12:54 PM, deadalnix wrote: On Thursday, 26 February 2015 at 16:57:51 UTC, Andrei Alexandrescu wrote: On 2/26/15 8:51 AM, Steven Schveighoffer wrote: As talked about before, running dtors in the originating thread can solve

Re: A Refcounted Array Type

On 2015-02-23 22:15:46 +, Walter Bright said: int* count; [...] if (count --*count == 0) [...] Careful! This isn't memory safe and you have to thank the GC for it. If you ever use RCArray as a member variable in a class, the RCArray destructor is going to be called from a random

Re: D/Objective-C 64bit

On 2014-11-18 09:07:10 +, Christian Schneider said: This is what I came up with so far: override KeyboardView initWithFrame(NSRect frame) [initWithFrame:] { //my stuff return cast(KeyboardView) super.initWithFrame(frame) ; } Why not use a constructor and let the compiler manage

Re: D/Objective-C 64bit

On 2014-11-04 09:07:08 +, Christian Schneider schnei...@gerzonic.net said: Ok, some more info: I changed the mapping in tableview.d to: void setDoubleAction(void __selector(ObjcObject)) [setDoubleAction:] ; That's indeed the best way to do it. This should be the way to do it. Now in

Re: D/Objective-C 64bit

On 2014-11-01 10:47:54 +, Jacob Carlborg d...@me.com said: On 2014-11-01 01:58, Michel Fortin wrote: That said, there are other parts of D/Objective-C that could pose difficulties to existing languages tools, some syntactic (__selector, or this.class to get the metaclass) this.class

Re: D/Objective-C 64bit

On 2014-10-30 07:13:08 +, Jacob Carlborg d...@me.com said: I had a look at your fix. I see that you added a call to release in the destructor. Just for the record, there's no guarantee that the destructor of a GC allocated object gets run, at all. D/Objective-C never allocates

Re: D/Objective-C 64bit

On 2014-10-30 09:16:34 +, Martin Nowak c...@dawg.eu said: On Tuesday, 11 March 2014 at 18:23:08 UTC, Jacob Carlborg wrote: A DIP is available here [1] and the latest implementation is available here [2]. [1] http://wiki.dlang.org/DIP43 Instead of adding the selector syntaxsyntax you

Re: D mention on developer.apple.com

On 2014-09-27 10:02:59 +, Jacob Carlborg d...@me.com said: On 2014-09-27 11:05, ponce wrote: - and no exceptions, just because The Objective-C frameworks by Apple basically never throw exceptions. There's that. Also, remember Walter's fear of ARC in D that would be bloating the

D mention on developer.apple.com

Maybe this will be of interest to someone. D was mentioned on the official Swift Blog today: Swift borrows a clever feature from the D language: these identifiers expand to the location of the caller when evaluated in a default argument list. -- Building assert() in Swift, Part 2: __FILE__

Re: More radical ideas about gc and reference counting

On 2014-05-11 08:29:13 +, Walter Bright newshou...@digitalmars.com said: Again, O-C and C++/CX ARC are not memory safe because in order to make it perform they provide unsafe escapes from it. But D could provide memory-safe escapes. If we keep the current GC to collect cycles, we could

Re: More radical ideas about gc and reference counting

On 2014-05-11 19:37:30 +, Walter Bright newshou...@digitalmars.com said: On 5/11/2014 5:52 AM, Michel Fortin wrote: On 2014-05-11 08:29:13 +, Walter Bright newshou...@digitalmars.com said: Again, O-C and C++/CX ARC are not memory safe because in order to make it perform they provide

Re: More radical ideas about gc and reference counting

On 2014-05-11 21:41:10 +, Walter Bright newshou...@digitalmars.com said: Your proposal still relies on a GC to provide the memory safety, and has no inherent protection against GC pauses. Your idea has a lot of merit, but it is a hybrid ARC/GC system. If you thread carefully you can

Re: From slices to perfect imitators: opByValue

On 2014-05-08 03:58:21 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: So there's this recent discussion about making T[] be refcounted if and only if T has a destructor. That's an interesting idea. More generally, there's the notion that making user-defined types as powerful

Re: More radical ideas about gc and reference counting

On 2014-05-06 12:04:55 +, Manu via Digitalmars-d digitalmars-d@puremagic.com said: Notably, I didn't say 'phones'. Although I think they do generally fall into this category, I think they're drifting away. Since they run full OS stack's, it's typical to have unknown amounts of free memory

Re: More radical ideas about gc and reference counting

On 2014-05-04 09:00:45 +, Marc Schütz schue...@gmx.net said: On Saturday, 3 May 2014 at 11:12:56 UTC, Michel Fortin wrote: Or turn the rule on its head: make it so having a destructor makes the heap memory block reference counted. With this adding a destructor always cause deterministic

Re: More radical ideas about gc and reference counting

On 2014-05-01 17:35:36 +, Marc Schütz schue...@gmx.net said: Maybe the language should have some way to distinguish between GC-managed and manually-managed objects, preferably in the type system. Then it could be statically checked whether an object is supposed to be GC-managed, and

Re: GC vs Resource management.

On 2014-05-03 18:27:47 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: Interesting, we haven't explored that. The most problematic implication would be that classes with destructors will form a hierarchy separate from Object. Seems like people have been ignoring my two posts

Re: More radical ideas about gc and reference counting

On 2014-04-30 21:51:18 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: I'm thinking e.g. non-interlocked refcounts go like 1, 3, 5, ... and interlocked refcounts go like 2, 4, 6, ... Then you do an unprotected read of the refcount. If it's odd, then it's impossible to having

Re: DIP61: Add namespaces to D

On 2014-04-26 09:31:51 +, Walter Bright newshou...@digitalmars.com said: 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

Re: DIP61: Add namespaces to D

On 2014-04-26 19:13:52 +, Walter Bright newshou...@digitalmars.com said: I think that trying to be compatible with C++ templates is utter madness. But we can handle namespaces. I'd argue that templates aren't the difficult part. Having struct/class semantics ABI-compatible with C++ is

Re: DIP60: @nogc attribute

On 2014-04-23 09:50:57 +, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com said: On Tuesday, 22 April 2014 at 19:42:20 UTC, Michel Fortin wrote: Objective-C isn't memory safe because it lets you play with raw pointers too. If you limit yourself to ARC-managed pointers (and avoid

Re: DIP60: @nogc attribute

On 2014-04-23 04:33:00 +, Walter Bright newshou...@digitalmars.com said: On 4/22/2014 12:42 PM, Michel Fortin wrote: On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said: Memory safety is not a strawman. It's a critical feature for a modern language, and will

Re: DIP60: @nogc attribute

On 2014-04-22 17:52:27 +, Steven Schveighoffer schvei...@yahoo.com said: Even doing it the way they have seems unnecessarily complex, given that iOS 64-bit was brand new. Perhaps it's faster that way due to some caching effect. Or perhaps it's to be able to have static constant string

Re: DIP60: @nogc attribute

On 2014-04-22 19:02:05 +, Walter Bright newshou...@digitalmars.com said: Memory safety is not a strawman. It's a critical feature for a modern language, and will become ever more important. What you don't seem to get is that ARC, by itself, is memory-safe. Objective-C isn't memory safe

Re: DIP60: @nogc attribute

On 2014-04-18 23:48:43 +, Walter Bright newshou...@digitalmars.com said: On 4/18/2014 3:02 PM, Michel Fortin wrote: Objective-C enables ARC by default for all pointers to Objective-C objects. Since virtually all Objective-C APIs deal with Objective-C objects (or integral values), if you

Re: DIP60: @nogc attribute

On 2014-04-18 20:40:06 +, Walter Bright newshou...@digitalmars.com said: O-C doesn't use ARC for all pointers, nor is it memory safe. @safe would be very easy to implement in Objective-C now that ARC is there. This has got me thinking. Ever heard C is the new assembly? I think this

Re: DIP60: @nogc attribute

On 2014-04-17 03:13:48 +, Manu via Digitalmars-d digitalmars-d@puremagic.com said: Obviously, a critical part of ARC is the compilers ability to reduce redundant inc/dec sequences. At which point your 'every time' assertion is false. C++ can't do ARC, so it's not comparable. With proper

Re: DIP60: @nogc attribute

On 2014-04-17 17:29:02 +, Walter Bright newshou...@digitalmars.com said: On 4/17/2014 5:34 AM, Manu via Digitalmars-d wrote: People who care would go to the effort of manually marking weak references. And that's not compatible with having a guarantee of memory safety. Auto-nulling weak

Re: DIP60: @nogc attribute

On 2014-04-16 23:20:07 +, Walter Bright newshou...@digitalmars.com said: On 4/16/2014 3:42 PM, Adam Wilson wrote: ARC may in fact be the most advantageous for a specific use case, but that in no way means that all use cases will see a performance improvement, and in all likelihood, may