Re: Killing the comma operator

On Wednesday, 11 May 2016 at 13:29:56 UTC, Gopan wrote: int x; while( scanf("%d", ), x!= 0) // until user input 0. { //do something with x } Without the comma operator, I would have to repeat the scanf statement. int x; scanf("%d", ); while(x != 0) { //do something with x

Re: Version block "conditions" with logical operators

On 10/05/2016 12:12, Tomer Filiba wrote: Alternatively, an isVersion(x) predicate that I could use in a static if could do the trick -- although I think ``version(x || y)`` is more readable than ``static if (isVersion(x) || isVersion(y))`` This is actually longer for 2 arguments, but can scale

Re: C#7 features

On Friday, 6 May 2016 at 23:51:59 UTC, Steven Schveighoffer wrote: Of COURSE D supports local ref variables: struct RefVar(T) { private T * var; this(ref T v) { var = } auto get() { return *var; } alias this get; } ref get() return {... Which is unsafe even if the ctor is marked

Re: [OT] Swift removing minor features to piss me off

On Thursday, 28 April 2016 at 22:37:41 UTC, H. S. Teoh wrote: I find for(;;) far more logical than other vacuous workarounds like while(1) or while(true). It's only because of C that all the for arguments can be left out, I'd rather have: while {...} I.e. it defaults to true. 'A while' is

Re: [OT] Swift removing minor features to piss me off

On Friday, 29 April 2016 at 06:27:07 UTC, Jacob Carlborg wrote: In an ideal world the language would support trailing delegate syntax allowing this to work without any language support: forever { } Translated to: forever({ }); Or maybe with macros supporting a trailing statement as the

Re: [OT] Swift removing minor features to piss me off

On Thursday, 28 April 2016 at 19:45:47 UTC, Steven Schveighoffer wrote: If you don't want to mutate it, don't put var in the parameter name. I put var there because I wanted to mutate it. Swift requires that already. It just now won't let you do it in the parameter declaration, you have to

Re: [OT] Swift removing minor features to piss me off

On Thursday, 28 April 2016 at 18:49:54 UTC, Steven Schveighoffer wrote: 1. Swift 3 will no longer allow mutable variables as parameters. Instead, your parameters will be immutable, or reference (inout). To fix this, you can assign your immutable variable to a mutable one (immutability is

Re: Instantiate!(Template, args) in Phobos?

On 25/04/2016 11:16, Nick Treleaven wrote: On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote: alias Instantiate(alias Template, Params...) = Template!Params; Ah, maybe I'd even seen this in passing and forgot. Good point about aliasSeq template elements, let's make this public.

Re: Instantiate!(Template, args) in Phobos?

On Friday, 22 April 2016 at 19:09:40 UTC, David Nadlinger wrote: From std.meta: --- /* * Instantiates the given template with the given list of parameters. * * Used to work around syntactic limitations of D with regard to instantiating * a template from an alias sequence (e.g. T[0]!(...)

Re: Line spacing for '///ditto' on the website

On Saturday, 23 April 2016 at 20:50:31 UTC, Adam D. Ruppe wrote: I still can't get over the ridiculous grey constraints. WTF. It's much better reading signatures than before. But what we could do is add a margin-bottom to them if needed, while keeping the others hugged up. Good idea,

Re: Who wore it better?

On Friday, 15 April 2016 at 18:46:01 UTC, Steven Schveighoffer wrote: inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) Might be nice if inout applied to template parameter types: T[] overlap(inout T)(T[] r1, T[] r2); If it wasn't for the virtual function issue, I wonder if inout would

Re: Instantiate!(Template, args) in Phobos?

On 22/04/2016 14:40, Steven Schveighoffer wrote: OK, I get it. I think this used to work, but I think D has long since disallowed direct access to eponymous members. So what you really want to do is: staticEx!(Exception, msg)!(file, line), but of course this doesn't follow proper grammar. I

Re: Instantiate!(Template, args) in Phobos?

On 21/04/2016 18:03, Steven Schveighoffer wrote: This doesn't work? alias staticEx(string msg, string file = __FILE__, size_t line = __LINE__) = staticEx!(Exception, msg).staticEx!(file, line); No, nor using the module dot prefix `= .staticEx!(...).staticEx` either: staticex.d(3): Error:

Instantiate!(Template, args) in Phobos?

Hi, There doesn't seem to be something like this in Phobos: alias Instantiate(alias Template, T...) = Template!T; Here's an example of why I need it: alias staticEx(string msg, string file = __FILE__, size_t line = __LINE__) = Instantiate!(.staticEx!(Exception, msg), file, line);

Throw static exception - Re: std.experimental.allocator.make should throw on out-of-memory

On Wednesday, 20 April 2016 at 19:32:01 UTC, Basile Burg wrote: a system exist to throw @nogc exceptions that would work in this case (the message doesn't have to be customized so it can be static): @nogc @safe void throwStaticEx(T, string file = __FILE__, size_t line = __LINE__)() {

Re: [PRs] How to update on Github

On Tuesday, 19 April 2016 at 13:34:24 UTC, John Colvin wrote: On Tuesday, 19 April 2016 at 13:05:35 UTC, tcak wrote: I would recommend making a copy of the whole repository locally before any of that just in case you mess something up, at least while you're not as confident with git. Isn't

Re: Who wore it better?

On Friday, 15 April 2016 at 17:24:19 UTC, Andrei Alexandrescu wrote: inout(T)[] overlap(T)(inout(T)[] r1, inout(T)[] r2) @trusted BTW, why is overlap undocumented - is ctfe support a good enough reason? https://github.com/dlang/phobos/blob/v2.071.0/std/array.d#L715 I've thought about

Re: DIP64: Attribute Cleanup

On Sunday, 17 April 2016 at 12:05:03 UTC, Anonymous5 wrote: If attributes are well split into sub categories, we could justify that a sub category will have @ and another not (e.g protection attributes: not @, functions attributes: @). The list of attributes that's not classified is: +

Re: So what does (inout int = 0) do?

On Sunday, 17 April 2016 at 14:30:59 UTC, QAston wrote: You've got lucky with pure (modulo corner cases) and ctfe, much less lucky with @safe, @trusted, @system, inout, shared, scope, property. The @safe troika is a good design (except @safe should be the default), the implementation is

Re: So what does (inout int = 0) do?

On 16/04/2016 12:40, Marc Schütz wrote: What are the plans for DIP25's `return` attribute? Because with it, the compiler has enough information to know that the return value aliases `s`: const(T)[] replaceSlice(T)(const(T)[] s return, in T[] slice, in T[] replacement); If the function is

Re: So what does (inout int = 0) do?

On 15/04/2016 04:10, Andrei Alexandrescu wrote: Commenting it out yields a number of unittest compilation errors, neither informative about the root of the problem and indicative as to how the parameter solves it. ... 2. There needs to be documentation for people working on the standard

Re: So what does (inout int = 0) do?

On Friday, 15 April 2016 at 04:23:29 UTC, Jonathan M Davis wrote: Certainly, there have been a few times that it's come up in D.Learn when folks ask what the heck it is, so there should be a few posts floating around with an explanation. This is the only useful post that I could find in a

Re: @nogc inconsistent for array comparison depending on mutability of elements

On Friday, 8 April 2016 at 10:11:43 UTC, Rene Zwanenburg wrote: On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote: If the comparison with b shouldn't be allowed, I suggest we add opEquals to std.range.only. This removes a need to import std.algorithm.equal and reduces bracket

Re: proposed syntax for tuple: t{} and TypeTuple: T{} (cf precedent of q{...})

On Tuesday, 5 April 2016 at 14:00:46 UTC, ag0aep6g wrote: I'm not sure if the new syntax is worth adding, though. `T{...}` (or `T[...]`) saves just one character over `T!(...)`. The latter can be done without touching the language. For the value tuple, one can do `alias t =

Re: @nogc inconsistent for array comparison depending on mutability of elements

On Friday, 8 April 2016 at 03:14:40 UTC, Xinok wrote: On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote: @nogc unittest { int[2] a = [1, 2]; assert(a == [1, 2]); // OK immutable(int)[2] b = [1, 2]; assert(b == [1, 2]); // fail: array literal may cause allocation } Is

Re: emit: generalizes map, filter, joiner [proposal + implementation]

On Wednesday, 23 March 2016 at 17:43:07 UTC, Tamas wrote: On Wednesday, 23 March 2016 at 17:29:55 UTC, Nick Treleaven wrote: On Monday, 21 March 2016 at 23:09:27 UTC, Tamas wrote: On Monday, 21 March 2016 at 11:48:52 UTC, Seb wrote: Could you try to point out whats wrong with map & filter?

Re: emit: generalizes map, filter, joiner [proposal + implementation]

On Monday, 21 March 2016 at 23:09:27 UTC, Tamas wrote: On Monday, 21 March 2016 at 11:48:52 UTC, Seb wrote: Could you try to point out whats wrong with map & filter? It's hard to do stuff like this: assert(9.iota.emit!(int,(put,a){if(a%2) put(a*a); if(a%3==0)

Re: Question about version ( ) keyword

On Monday, 21 March 2016 at 14:51:48 UTC, Vincent R wrote: version( CRuntime_Glibc ) || version( FreeBSD ) || version (Solaris) { As a workaround, you can do it with static if and version strings: http://forum.dlang.org/post/op.vkshabecot0hzo@las-miodowy

Re: [Request] A way to extract all instance of X from a range

On Tuesday, 22 March 2016 at 20:09:51 UTC, Matthias Bentrup wrote: It is logically just a combination of map and concat (which turns a range of ranges into a combined range, but I think that one is missing in the std lib too). http://dlang.org/phobos/std_range.html#.chain

Re: [Request] A way to extract all instance of X from a range

On 14/03/2016 11:32, thedeemon wrote: filter_map : ('a -> 'b option) -> 'a t -> 'b t "filter_map f e returns an enumeration over all elements x such as f y returns Some x, where y is an element of e." It is really convenient and comes handy in many situations. However it requires some common

Re: Defer in D

On 20/03/2016 16:57, Nick Treleaven wrote: void opCall(ARGS...)(void delegate(ARGS) call, ARGS args) { stack.put(() => call(args)); } Maybe this method would be nice (does the same thing): Deferrer d; ... d.capture!writeln("i = ", i); The name capture makes it clearer

Re: Defer in D

On 20/03/2016 16:18, Bauss wrote: defer((int i) => writeln(i), i); If it was defer(() => writeln(i)), would that do the same? (Dpaste won't seem to let me edit your example on my tablet). (or on my laptop) No that's not the same, since the reference to i does not change when doing:

Re: Defer in D

On Saturday, 19 March 2016 at 23:16:40 UTC, Xinok wrote: I took a quick look through Phobos but didn't see anything similar so I wrote this as a proof of concept and to elicit discussion. This also works should the function throw rather than return gracefully.

__guard statement to shadow nullable variables with NonNull wrapper

From the thread about Kotlin and null safety: http://forum.dlang.org/post/yxfdycdtgdesbsozv...@forum.dlang.org On Tuesday, 23 February 2016 at 06:49:46 UTC, Tobias Müller wrote: rsw0x wrote: D has this too, but only for nullable types afaik. if(byte* ptr =

Re: Yet another leak in the sinking ship of @safe

On Tuesday, 23 February 2016 at 11:04:31 UTC, Nick Treleaven wrote: Assuming we don't want to disallow slice.ptr in @safe code, maybe we could have the compiler insert this code before reading slice.ptr: version(D_NoBoundsChecks) else if (slice.length == 0) throw new RangeError("Unsafe

Re: Yet another leak in the sinking ship of @safe

On Friday, 19 February 2016 at 19:00:35 UTC, H. S. Teoh wrote: Here's an existing one that plugs another hole in the cheese grater: https://github.com/D-Programming-Language/phobos/pull/4009 That pull mentions the issue of *arr[$..$].ptr being unsafe:

Re: @mutable

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 attributes) to imply auto: const

Re: @mutable

On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote: I've adapted my previous DIP on lazy initialization to make it usable for logical immutability, as is useful for reference counting, among other things: http://wiki.dlang.org/DIP89 From the DIP: The second rule (@system)

Re: @mutable

On Sunday, 21 February 2016 at 15:03:39 UTC, Marc Schütz wrote: I've adapted my previous DIP on lazy initialization to make it usable for logical immutability, as is useful for reference counting, among other things: http://wiki.dlang.org/DIP89 BTW the Usage section still uses lazy. I think

Re: Head Const

On Tuesday, 16 February 2016 at 10:32:45 UTC, Timon Gehr wrote: struct S{ int[] a; void foo()headconst{ a[0]=1; // ok // arr.length=2 // error } } void main(){ headconst(S) s([0,2,3]); s.foo(); assert(s.a==[1,2,3]); } How to do this in the library?

Re: `alias this` pointers and typeof(null)

On Friday, 29 January 2016 at 15:38:26 UTC, Benjamin Thaut wrote: On Friday, 29 January 2016 at 13:38:20 UTC, Tomer Filiba wrote: I can change all such invocations into ``func(FooPtr(null))`` but it's tedious and basically requires me to compile tens of times before I'd cover everything. Is

Re: DIP 88: Simple form of named parameters

On Saturday, 23 January 2016 at 14:19:03 UTC, Jacob Carlborg wrote: This is mostly to prevent ugly hacks like Flag [1]. http://wiki.dlang.org/DIP88 [1] https://dlang.org/phobos/std_typecons.html#.Flag I agree Flag is a bit ugly to use, but IIUC this proposal does not enforce the use of a

Re: [dlang.org] new forum design

On Tuesday, 19 January 2016 at 04:53:01 UTC, Vladimir Panteleev wrote: On Monday, 18 January 2016 at 20:51:23 UTC, Nick Treleaven wrote: This would really help on my nexus tablet, it's painful selecting a text block of lines that flow off the visible screen. Where does that happen? Sorry,

Re: [dlang.org] new forum design

Thanks for developing the forum software. One feature request: if there's selected text in the message body when clicking reply, only quote the selected text rather than the whole message body. This is what my email client does. This would really help on my nexus tablet, it's painful

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

On Monday, 18 January 2016 at 15:36:09 UTC, Manu wrote: One more time... Assuming: void func(const CustomString , const CustomString ); void func(ref const(CustomString) s1, ref const(CustomString) s2); C++: func("hello", "world"); D: auto dumb_name = CustomString("hello"); auto

Re: How about appender.put() with var args?

On 16/04/2015 18:25, Nick Treleaven wrote: I think this works: import std.range : only; app.put(only(foo, var, bar)); OK, that doesn't work, and an array doesn't either (which was my assumption): app.put([foo, var, bar]); // NG If it had, I thought only might be more efficient than

Re: How about appender.put() with var args?

On Wednesday, 15 April 2015 at 20:40:04 UTC, Márcio Martins wrote: I guess chain could work in some cases, and are not that bad on the aesthetic side, I supposed. However having to include std.range just for that, and more importantly, all parameters having to be the same type, as opposed to

Re: Replace core language HexStrings with library entity

On 18/03/2015 14:45, H. S. Teoh via Digitalmars-d wrote: On Wed, Mar 18, 2015 at 07:45:54PM +1100, Daniel Murphy via Digitalmars-d wrote: Kagamin wrote in message news:pltiewdojqrmgxrwh...@forum.dlang.org... The compiler lexer can be of arbitrary complexity, because it's already written. If

Re: Replace core language HexStrings with library entity

On 17/03/2015 03:28, Andrei Alexandrescu wrote: On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to make its removal a net positive. q delimited strings. No one uses them (used once in all of Phobos). They are obscure

Re: `return const` parameters make `inout` obsolete

On 16/03/2015 14:17, Zach the Mystic wrote: char* fun(return const char* x); Compiler has enough information to adjust the return type of `fun()` to that of input `x`. This assumes return parameters have been generalized to all reference types. Destroy. inout can be used for local variables

Re: Replace core language HexStrings with library entity

On 17/03/2015 01:45, Daniel Murphy wrote: Nick Treleaven wrote in message news:me6jo4$ca$1...@digitalmars.com... 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) You can take them when you pry them from my cold, dead hands. These are

Re: Replace core language HexStrings with library entity

On 17/03/2015 11:34, Biotronic wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) And while we're at it, why not remove those pesky base-10 literals as well? Shouldn't

Re: A few notes on choosing between Go and D for a quick project

On 17/03/2015 10:31, Almighty Bob wrote: It's far more useful for csvReader to return a type I know and can use than it is to obscure the return type for the sake of some philosophical ideal of increasing encapsulation. Part of the art of API design is to hide implementation where it's not

Re: Replace core language HexStrings with library entity

On 17/03/2015 12:42, Daniel Murphy wrote: Nick Treleaven wrote in message news:me950a$2boc$1...@digitalmars.com... On 17/03/2015 03:28, Andrei Alexandrescu wrote: On a higher level: there's no subset of the language that's at the same time sufficiently complex and sufficiently obscure to

Re: Replace core language HexStrings with library entity

On 15/03/2015 19:46, Walter Bright wrote: Any other ideas on things that can removed from the core language and replaced with library entities? 0b1010 binary literals (even though C++11 supports them) 0xABCD hex literals (but useful for porting C) Also, there are some things which I think are

Re: The next iteration of scope

On 15/03/2015 19:11, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Sunday, 15 March 2015 at 17:31:17 UTC, Nick Treleaven wrote: I too want a scope attribute e.g. for safe slicing of static arrays, etc. I'm not sure if it's too late for scope by default though, perhaps. If we get

Re: The next iteration of scope

On 16/03/2015 04:00, Zach the Mystic wrote: struct RC(T) if(is(T == class)) { scope T payload; T borrow() return {// `return` applies to `this` return payload; } } ... Also, what exactly does the `scope` on T payload get you? It means if you forget the `return`

Re: Replace core language HexStrings with library entity

On 16/03/2015 14:22, Kagamin wrote: On Monday, 16 March 2015 at 12:53:24 UTC, Nick Treleaven wrote: /++/ - If we made /**/ nest, /++/ would be unnecessary I'd just drop nested comments: block comments and version(none) are good enough. They need to nest in order to allow block comments in

Re: A few notes on choosing between Go and D for a quick project

On 15/03/2015 05:06, Walter Bright wrote: In D we have some implicit casts also because the cast(int)x syntax is dangerous. But now we can write safe casts with the int(x) syntax, so there's less need of naked implicit casts. Again, too many casts can cause bugs. You can have safe wrappers

Re: The next iteration of scope

On 15/03/2015 14:10, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: Here's the new version of my scope proposal: http://wiki.dlang.org/User:Schuetzm/scope2 It's still missing real-life examples, a section on the implementation, and a more formal specification, as well as a discussion of

Re: Post increment and decrement

On 12/03/2015 10:14, monarch_dodra wrote: On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote: Observation Nr. 1 People prefer to write var++ instead of ++var. The root of your reasoning stems from this observation, which I argue is wrong. The recommendation has always been to chose

Re: RCArray is unsafe

On 04/03/2015 08:55, Ivan Timokhin wrote: void main() { auto arr = RCArray!int([0]); foo(arr, arr[0]); } void foo(ref RCArray!int arr, ref int val) { { auto copy = arr; //arr's (and copy's) reference counts are both 2

Re: RCArray is unsafe

On 03/03/2015 13:05, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: The bigger problem is that it's relying on a convention. The RC wrapper needs to be constructed in a particular way that's easy to get wrong and that the compiler has no way to check for us. Maybe the compiler could

Re: DIP74: Reference Counted Class Objects

On 26/02/2015 22:04, Andrei Alexandrescu wrote: On 2/26/15 2:03 PM, Brian Schott wrote: The DIP states that Any attributes are allowed on these methods., but later states The complexity of this code underlies the importance of making opAddRef and especially opRelease nothrow. Should the DIP

Disallow destroy(structPtr)?

Hi, The following code is supposed to destroy the struct instance: import std.stdio; struct S{ ~this(){destruct.writeln;} } auto p = new S; destroy(p); end.writeln; It works correctly if I use destroy(*p), but the above code could perhaps be statically

Re: let (x,y) = ...

On 19/02/2015 04:38, thedeemon wrote: int x, y, z, age; string name; let (name, age) = getTuple(); // tuple let (x,y,z) = argv[1..4].map!(to!int); // lazy range let (x,y,z) = [1,2,3]; // array SomeStruct s; let (s.a, s.b) = tuple(3, piggies); Alternatively

Re: let (x,y) = ...

On 19/02/2015 17:00, Nick Treleaven wrote: Alternatively std.typetuple.TypeTuple can be used instead of let not for ranges and arrays though Yes, but `tuple` overloads could be added for those. Or not - the length isn't known at compile-time. Tuple already supports construction from a

Re: Template constraints

On 16/02/2015 19:31, Steven Schveighoffer wrote: Wait, isn't this OK? struct S(T) if(is(T == int)) { ... } struct S(T) if(is(T == double)) { ... } ... They may even be in multiple modules. Is this not overloading of types? I don't think this should be frowned upon. OK, so the idea

Re: let (x,y) = ...

On 19/02/2015 14:59, John Colvin wrote: On Thursday, 19 February 2015 at 13:52:29 UTC, Nick Treleaven wrote: On 19/02/2015 04:38, thedeemon wrote: int x, y, z, age; string name; let (name, age) = getTuple(); // tuple let (x,y,z) = argv[1..4].map!(to!int); // lazy range let (x,y,z)

Re: Plan for Exceptions and @nogc?

On 17/02/2015 07:28, weaselcat wrote: Would RefCounted!T being @nogc help alleviate this issue? I think Andrei once said that was a good solution for exceptions. I think the stumbling block is that if T contains indirections, RefCounted calls GC.addRange on the T*, which currently violates

Re: Plan for Exceptions and @nogc?

On 17/02/2015 16:15, Nick Treleaven wrote: Would RefCounted!T being @nogc help alleviate this issue? I think Andrei once said that was a good solution for exceptions. Or rather that refcounting would be appropriate for exceptions, not necessarily RefCounted. (The compiler can't generate

Re: Proposal : aggregated dlang git repository

On 11/02/2015 13:52, Dicebot wrote: Biggest problem with RefCounted is that it is a struct. Thus it is inherently incompatible with polymorphic world. For Unique, (which admittedly is a simpler concept), it does work with polymorphic types, see:

Re: Setting error/removal dates for deprecated features

On 10/02/2015 10:59, Daniel Murphy wrote: DDMD currently relies on allocating classes on the stack with 'scope' If something like DIP 69 is implemented, it seems we could support this safely. Then we would only need to deprecate the scope attribute at a class definition.

Re: Another idiom I wish were gone from phobos/druntime

On 05/02/2015 01:50, H. S. Teoh via Digitalmars-d wrote: On Thu, Feb 05, 2015 at 01:34:47AM +, deadalnix via Digitalmars-d wrote: On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote: Would introduce an exception to our brace-on-its-line rule. Which is already

Re: Another idiom I wish were gone from phobos/druntime

On 05/02/2015 08:56, Kagamin wrote: On Thursday, 5 February 2015 at 01:34:49 UTC, deadalnix wrote: On Thursday, 5 February 2015 at 01:07:56 UTC, Andrei Alexandrescu wrote: Would introduce an exception to our brace-on-its-line rule. Will I start the next world war if I mention this rule is

Re: Should we remove int[$] before 2.067?

On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote: immutable[][$] a2 = [[1,2], [3,4]]; // a static array of mutable dynamic array of immutable ints static assert(is(typeof(a2) == immutable(int)[][2])); ... The type deduction will provide powerful way to type variables. Yes,

Re: Should we remove int[$] before 2.067?

On 30/01/2015 17:01, Kenji Hara via Digitalmars-d wrote: 2015-01-31 1:53 GMT+09:00 Nick Treleaven via Digitalmars-d digitalmars-d@puremagic.com: This version of staticArray allows the user to (optionally) specify the element type. How the API can replace following declaration with ? auto

Re: Should we remove int[$] before 2.067?

On 30/01/2015 16:44, Kenji Hara via Digitalmars-d wrote: The new feature, I call it Partial type deduction, is not only for static array length. Yes, I think the other improvements are useful, but [$] is not strictly necessary. Maybe [$] will turn out to be worth having, but I'm not sure

Re: Should we remove int[$] before 2.067?

On 30/01/2015 14:47, Andrei Alexandrescu wrote: The recent int[$] feature seems to fail that test. That feature, and in fact more, can be done trivially with library code: http://dpaste.dzfl.pl/f49a97e35974. +1. Also discussed here: https://issues.dlang.org/show_bug.cgi?id=8008#c8

Re: Should we remove int[$] before 2.067?

On 30/01/2015 16:53, Nick Treleaven wrote: This version of staticArray allows the user to (optionally) specify the element type. Actually, I'm having trouble implementing staticArray like that, perhaps there are compiler issues causing problems. Using this: T[len] staticArray(T, size_t

Re: FAQ for newbies who see pure @safe nothrow @nogc

On 29/01/2015 17:51, Jonathan Marler wrote: Nick I'm putting together the FAQ right now. I don't quite understand this proposal. Could you outline it for me? I'd like to know exactly what words would require an '@' symbol. What is the criteria for when to use an '@' and when not to use one?

Re: accept @pure @nothrow @return attributes

On 28/01/2015 22:44, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Could it be that new languages define grammars that are more robust than the one used by C? Like Go? We're not going to significantly change the structural syntax of D, so it doesn't seem that

Re: FAQ for newbies who see pure @safe nothrow @nogc

On 29/01/2015 15:54, Jonathan Marler wrote: Like this: abstract class MyClass { } @abstract void myfunc(); See the inconsistency? You're gonna end up with alot of these types of inconsistencies. In addition, you've made the rule of when to use the '@' symbol more complex. Before it was, Use

Re: accept @pure @nothrow @return attributes

On 27/01/2015 18:01, Jonathan Marler wrote: On Tuesday, 27 January 2015 at 17:18:11 UTC, Nick Treleaven wrote: On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote: abstract also applies to classes, as does final. Yes, but they actually only affect the *functions* belonging to the

Re: accept @pure @nothrow @return attributes

On 26/01/2015 21:20, bearophile wrote: Walter Bright: Previously, it's all been advocacy and break my code Breaking the code should be justified by a worth gain. This patch is of negative value. It doesn't break code.

Re: accept @pure @nothrow @return attributes

On 27/01/2015 02:27, Jonathan M Davis via Digitalmars-d wrote: You're right. I forgot about those two. But it's still the case that the number of function attributes that don't have @ on them is_far_ greater than the number of those that do. But I explained that most function attributes don't

Re: accept @pure @nothrow @return attributes

On 27/01/2015 10:20, Jacob Carlborg wrote: How is this change going to help when there's still a bunch of attributes that can not be prefixed with '@', immutable, const, public and so on? Those can apply to variables too. We could use built-in @attributes for functions only

Re: accept @pure @nothrow @return attributes

On 27/01/2015 16:49, Jonathan M Davis via Digitalmars-d wrote: abstract also applies to classes, as does final. Yes, but they actually only affect the *functions* belonging to the class, not the variables. A class is not a variable. Also, if we end up adding any new attributes later,

Re: accept @pure @nothrow @return attributes

On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote: the increased visual noise definitely is not. Being able to ignore things starting with @ is useful when reading function signatures: @property const(T) @pure @nothrow foo(Arg arg, T bar) const ... So @ can actually be signal

Re: accept @pure @nothrow @return attributes

On 26/01/2015 17:07, Nick Treleaven wrote: and inout gained @attribute syntax too Actually inout can apply to local variables, so it shouldn't have a '@' by my logic.

Re: accept @pure @nothrow @return attributes

On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote: In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and

Re: Compile time iota

On 21/01/2015 19:15, zeljkog wrote: And good name staticIota, unlike TypeTuple. I always wonder what is raw tuple, TypeTuple or Tuple :) Yes, there's a DIP to rename std.typetuple to std.meta.list. I made a pull to do that (which goes further than the DIP), but I don't know if the

Re: Nicer anchors

On 30/12/2014 01:27, Adam D. Ruppe wrote: On Tuesday, 30 December 2014 at 01:18:39 UTC, Andrei Alexandrescu wrote: How would that achieve cross referencing? To be clear, what your change does is make links like this work, yes?

Re: Nicer anchors

On 30/12/2014 02:18, Vladimir Panteleev wrote: I'm not sure using numbers to distinguish overloads is a good idea. Such links would break easily. Note: that isn't part of Andrei's pull. Using numbers is the only workable way, other schemes would also break easily, probably moreso. I

Re: Worst Phobos documentation evar!

On 28/12/2014 17:09, Nick Treleaven wrote: On 28/12/2014 14:22, Joseph Rushton Wakeling via Digitalmars-d wrote: BTW is it just me, or are the various isSomething methods of std.traits not having documentation generated properly? See: http://dlang.org/phobos/std_traits.html ... and try

Re: Worst Phobos documentation evar!

On 28/12/2014 17:11, Nick Treleaven wrote: But for some reason codePoints and codeUnits are in between .encode.3 and .encode.4! I made a start on fixing Walter's points, and fixed the above: https://github.com/D-Programming-Language/phobos/pull/2825

Re: Worst Phobos documentation evar!

On 28/12/2014 14:22, Joseph Rushton Wakeling via Digitalmars-d wrote: BTW is it just me, or are the various isSomething methods of std.traits not having documentation generated properly? See: http://dlang.org/phobos/std_traits.html ... and try searching for, say, isBoolean, or isSomeString.

Re: Worst Phobos documentation evar!

On 28/12/2014 01:00, Walter Bright wrote: This is so bad there isn't even a direct link to it With newer dmd, there should be - I get .encode.4 as the anchor name. Thanks for merging that pull BTW. But for some reason codePoints and codeUnits are in between .encode.3 and .encode.4!

Re: Worst Phobos documentation evar!

On 28/12/2014 17:51, Russel Winder via Digitalmars-d wrote: Trying to fix this problem seems to require people who want to contribute to have to clone Phobos and submit pull requests. You can do it all from your browser if you want, check the Improve this page link at the top right of each

Re: Documenting parameters [was: Re: Worst Phobos documentation evar!]

On 28/12/2014 14:49, Joseph Rushton Wakeling via Digitalmars-d wrote: Is there an existing equivalent that can be used for template parameters? Template Params: or TemplateParams:, for example, don't work. You can just use Params: for them also. Perhaps separating them might be nice though.

<    1   2   3   4   5   >