Re: shared - i need it to be useful

On Monday, 22 October 2018 at 14:31:28 UTC, Timon Gehr wrote: On 22.10.18 16:09, Simen Kjærås wrote: On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote: module reborked; import atomic; void main()@safe{     auto a=new Atomic!int;     import std.concurrency;     spawn((shared(Atomic!i

Re: shared - i need it to be useful

On Monday, 22 October 2018 at 13:40:39 UTC, Timon Gehr wrote: module reborked; import atomic; void main()@safe{ auto a=new Atomic!int; import std.concurrency; spawn((shared(Atomic!int)* a){ ++*a; }, a); ++a.tupleof[0]; } Finally! Proof that MP is impossible. On the other hand,

Re: shared - i need it to be useful

On Monday, 22 October 2018 at 10:26:14 UTC, Timon Gehr wrote: module borked; void atomicIncrement(int* p)@system{ import core.atomic; atomicOp!("+=",int,int)(*cast(shared(int)*)p,1); } struct Atomic(T){ private T val; void opUnary(string op : "++")() shared @trusted { at

Re: Manu's `shared` vs the @trusted promise

On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote: (2) What's Wrong with That? The @trusted contract says that an @trusted function must be safe when called from an @safe function. That calling @safe function might be located in the same module, meaning it might have the same level o

Re: shared - i need it to be useful

On Sunday, 21 October 2018 at 13:24:49 UTC, Stanislav Blinov wrote: On Sunday, 21 October 2018 at 11:25:16 UTC, aliak wrote: When I say ok, I mean assuming the implementer actually wrote correct code. This applies to any shared method today as well. This ("ok") can only be achieved if the "imp

Re: shared - i need it to be useful

On Sunday, 21 October 2018 at 12:45:43 UTC, Stanislav Blinov wrote: On Sunday, 21 October 2018 at 05:47:14 UTC, Manu wrote: On Sat, Oct 20, 2018 at 10:10 AM Stanislav Blinov via Digitalmars-d wrote: Synchronized with what? You still have `a`, which isn't `shared` and doesn't require any atom

Re: shared - i need it to be useful

On Sunday, 21 October 2018 at 09:58:18 UTC, Walter Bright wrote: On 10/20/2018 11:08 AM, Nicholas Wilson wrote: You can if no-one else writes to it, which is the whole point of Manu's proposal. Perhaps it should be const shared instead of shared but still. There is no purpose whatsoever to da

Re: shared - i need it to be useful

On Sunday, 21 October 2018 at 09:50:09 UTC, Walter Bright wrote: On 10/20/2018 11:24 AM, Manu wrote: This is an unfair dismissal. It has nothing at all to do with fairness. It is about what the type system guarantees in @safe code. To repeat, the current type system guarantees in @safe code

Re: shared - i need it to be useful

On Sunday, 21 October 2018 at 09:04:34 UTC, Walter Bright wrote: On 10/20/2018 11:30 AM, Manu wrote: You can write an invalid program in any imaginable number of ways; that's just not an interesting discussion. What we're discussing is not an invalid program, but what guarantees the type sys

Re: shared - i need it to be useful

On Friday, 19 October 2018 at 18:00:47 UTC, Atila Neves wrote: Because int or int* does not have threadsafe member functions. https://dlang.org/phobos/core_atomic.html Atomic and thread-safe are two very different concepts. Thread-safe is more of an ecosystem thing - if there are ways to do

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 16:31:02 UTC, Stanislav Blinov wrote: You contradict yourself and don't even notice it. Per your rules, the way to open that locked box is have shared methods that access data via casting. Also per your rules, there is absolutely no way for the programmer to cont

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 21:54:55 UTC, Stanislav Blinov wrote: Manu, Erik, Simen... In what world can a person consciously say "casting is unsafe", and yet at the same time claim that *implicit casting* is safe? What the actual F, guys? In a world where the implicit casting always ends

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 14:19:41 UTC, Steven Schveighoffer wrote: On 10/18/18 10:11 AM, Simen Kjærås wrote: On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote: struct ThreadSafe {    private int x;    void increment()    {   ++x; // I know this is not shared, s

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 13:35:22 UTC, Steven Schveighoffer wrote: struct ThreadSafe { private int x; void increment() { ++x; // I know this is not shared, so no reason to use atomics } void increment() shared { atomicIncrement(&x); // use atomics, to avoid

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 13:09:10 UTC, Simen Kjærås wrote: Ergo... you can't have functions taking pointers to shared primitives. Ergo, `shared ` becomes a useless language construct. Yup, this is correct. But wrap it in a struct, like e.g. Atomic!int, and everything's hunky-dory. So

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 12:15:07 UTC, Stanislav Blinov wrote: On Thursday, 18 October 2018 at 11:35:21 UTC, Simen Kjærås wrote: On Thursday, 18 October 2018 at 10:08:48 UTC, Stanislav Blinov wrote: Manu, how is it that you can't see what *your own* proposal means??? Implicit casting f

Re: shared - i need it to be useful

On Thursday, 18 October 2018 at 10:08:48 UTC, Stanislav Blinov wrote: Manu, how is it that you can't see what *your own* proposal means??? Implicit casting from mutable to shared means that everything is shared by default! Precisely the opposite of what D proclaims. Well, sorta. But that's

Re: Passing $ as a function argument

On Sunday, 14 October 2018 at 15:27:07 UTC, Michael Coulombe wrote: On Sunday, 14 October 2018 at 14:35:36 UTC, lngns wrote: On Sunday, 14 October 2018 at 13:18:37 UTC, lngns wrote: That would require introducing a new type Or just use int with a negative number... That's how it's done in so

Re: Passing $ as a function argument

On Wednesday, 10 October 2018 at 23:04:46 UTC, James Japherson wrote: The whole point is not to use $ as an identifier but to specify to the compiler of that it can rewrite it. I know. I'm pointing out that as syntactic sugar, it can't be passed as an int. You seem to think that what the co

Re: Passing $ as a function argument

On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson wrote: Would be nice to be able to pass $ as a function argument to be used in automatic path length traversing. void foo(int loc) { return bar[loc]; } then foo($) would essentilly become foo(&) becomes ==> return bar[$

Re: BetterC and CTFE mismatch

On Wednesday, 26 September 2018 at 08:06:27 UTC, Sebastiaan Koppe wrote: Right now I am building a betterC application and I would have expected to be able to use the D standard library in CTFE. It seems this is not the case. Can anyone explain why? It seems to be an arbitrary limitation. ex

Re: OT: Bad translations

On Wednesday, 26 September 2018 at 02:12:07 UTC, Ali Çehreli wrote: On 09/24/2018 08:17 AM, 0xEAB wrote: > - Non-idiomatic translations of tech terms [2] This is something I had heard from a Digital Research programmer in early 90s: English message was something like "No memory left" and the

Re: What changes to D would you like to pay for?

On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote: Please answer these two questions if you're using or would like to use D, I have supplied my own answers as an example: 1. What D initiatives would you like to fund and how much money would you stake on each? (Nobody is going to hol

Re: Is this a bug ? (variable _param_0 cannot be read at compile time)

On Wednesday, 8 August 2018 at 13:10:58 UTC, learnfirst1 wrote: https://run.dlang.io/is/blpkb6 There is no reason the code just work without template, but try put the it into template the variable become into not readable ? Please don't post your issues in multiple forums. This is exactly wh

Re: An Optional!T and the implementation of the underlying type's opUnary

On Friday, 27 July 2018 at 12:52:09 UTC, aliak wrote: On Thursday, 26 July 2018 at 06:37:41 UTC, Simen Kjærås wrote: As for assigning to Optional!(immutable int), the language basically forbids this (cannot modify struct with immutable members). It would, as you say, cause problems when you can

Re: Whence came UFCS?

On Friday, 27 July 2018 at 13:38:26 UTC, Steven Schveighoffer wrote: On 7/27/18 7:24 AM, Simen Kjærås wrote: Arrays' .reverse, .sort and others were added in 0.24, but I can't find a download for anything before 0.50. Reverse and sort were properties (compiler built-ins), not extensions. If i

Re: Whence came UFCS?

On Friday, 27 July 2018 at 10:30:07 UTC, Jonathan M Davis wrote: It evolved out of D's member function call syntax for arrays - basically, for years before we had UFCS in D, we had UFCS for arrays. However, when and how that was added to arrays, I don't know. I don't recall it ever not being in

Re: An Optional!T and the implementation of the underlying type's opUnary

On Wednesday, 25 July 2018 at 21:59:00 UTC, aliak wrote: It needs to work with const as well and immutable too. immutable a = 3; auto b = -a; // is ok, should be ok with the optional as well. Plus T can be a custom type as well with "some" definition of opUnary. I can't seem to find any implem

Re: opCmp / opEquals do not actually support partial orders

On Thursday, 19 July 2018 at 10:14:34 UTC, Dominikus Dittes Scherkl wrote: On Wednesday, 18 July 2018 at 17:30:21 UTC, Jonathan M Davis wrote: On Tuesday, July 17, 2018 21:18:12 John Colvin via Digitalmars-d wrote: Just do what std.typecons.Proxy does and return float.nan for the incomparable c

Re: T.init, struct destructors and invariants - should they be called?

On Friday, 6 July 2018 at 12:31:50 UTC, FeepingCreature wrote: On Friday, 6 July 2018 at 12:10:58 UTC, Simen Kjærås wrote: The rest looks sensible to me, but I have to say this is bollocks. This Nullable never has to construct an S.init: struct Nullable(T) { ubyte[T.sizeof] _payload; b

Re: T.init, struct destructors and invariants - should they be called?

On Friday, 6 July 2018 at 10:44:09 UTC, FeepingCreature wrote: Why is this a problem? ("Just don't use S.init!") Well, for one it makes Nullable!S impossible. Nullable, if it is to be @nogc, *necessarily* has to construct an S.init struct member. The rest looks sensible to me, but I have to

Re: Would be nice if compiler gave more information!

On Thursday, 14 June 2018 at 11:30:46 UTC, DigitalDesigns wrote: object.Error@(0): Access Violation 0x00415999 0x0040A3B7 0x00518A2D 0x005751FD 0x005ABA41 0x005ABAEB 0x00525136 0x005246D6 0x005253E2 0x0066509D 0x00664F38 0x00529F68 0x77018744 in BaseThreadInitThunk 0x77C5582D in

Re: is(T t == U!n, U, int n)

On Wednesday, 13 June 2018 at 09:41:45 UTC, Luís Marques wrote: ...why can't I generalize it to match U!n, for some U, int n? template X(T) { static if(is(T t == U!n, U, int n)) U needs to be alias U, since S is not a type, but a template. This works: template X(T) { st

Re: Identifier hierarchy

On Monday, 11 June 2018 at 12:59:01 UTC, Mike Franklin wrote: On Monday, 11 June 2018 at 12:38:33 UTC, Luís Marques wrote: Just to check. If you have a piece of code like "foo.bar.baz", you can get the full hierarchy, for instance with stringof: static assert(foo.bar.baz.stringof == "foo

Re: Mixin templates are a pain at best, useless at worst for any non-trivial use case

On Tuesday, 5 June 2018 at 10:11:49 UTC, Ethan wrote: Exhibit A: https://run.dlang.io/is/a85Lbq I submitted a bug with the above code, and it was "helpfully" shut down with a link to the documentation and workaround. Congratulations. That's not the use case here, and to be quite honest this i

Re: Can anyone explain this?

On Tuesday, 5 June 2018 at 08:26:22 UTC, Nicholas Wilson wrote: writeln("Assert"); // this is not caught because the thrown throwable is not an exception Now that's plain false - If you replace the call to throwingFunc() with a string literal, you'll see it's properly caught. Also, the catch

Re: cycle dependencies

On Saturday, 2 June 2018 at 17:17:02 UTC, Neia Neutuladh wrote: On Friday, 1 June 2018 at 17:59:21 UTC, Steven Schveighoffer wrote: The .di file is just an interface, it doesn't know what's actually compiled in the binary. To put it another way, the compiler only generates a ModuleInfo (or de

Re: cycle dependencies

On Wednesday, 30 May 2018 at 20:57:32 UTC, DigitalDesigns wrote: Why is this a runtime issue? It is not as if the execution of static this are non-deterministic. The compiler and linker must order the calls in some way. Maybe this is what you mean by own object/linker? But even then, they woul

Re: Extend the call site default argument expansion mechanism?

On Wednesday, 16 May 2018 at 10:51:51 UTC, jmh530 wrote: On Wednesday, 16 May 2018 at 09:01:29 UTC, Simen Kjærås wrote: snip] struct Foo(int x) { int n = x; auto opDispatch(string s)() if (s == "bar") { n++; return n; }

Re: Extend the call site default argument expansion mechanism?

On Tuesday, 15 May 2018 at 15:02:36 UTC, jmh530 wrote: On Tuesday, 15 May 2018 at 14:52:46 UTC, Steven Schveighoffer wrote: [snip] It seems opDispatch isn't being used in the with statement. That seems like a bug, or maybe a limitation. I'm not sure how "with" works, but I assumed it would tr

Re: Module-level privacy

On Sunday, 13 May 2018 at 17:19:26 UTC, rumbu wrote: On Sunday, 13 May 2018 at 15:13:59 UTC, meppl wrote: Also, someone may say: I can see what happens in one and the same file. If there are two classes/structs in one file, they are "friends" and I dont need the "friend"-keyword anymore. That

Re: lazy evaluation of logical operators in enum definition

On Monday, 16 April 2018 at 05:57:01 UTC, Shachar Shemesh wrote: Consider the following program: struct S1 { enum member = 3; } struct S2 { enum member = 2; } struct S3 { } enum prop(T) = __traits(hasMember, T, "member") && T.member==3; pragma(msg, prop!S1); pragma(msg, prop!S2); pra

File names in string mixins

In a thread[0] over on D.learn, bauss suggested adding a second argument to MixinExpressions, such that mixin("foo()", "my mixin") compiles. The use case for the extra argument is as an identifier that will be used in error messages, where the current behavior is to create a virtual file name o

Re: What Is Python Developer Salary?

On Friday, 13 April 2018 at 10:00:00 UTC, bauss wrote: Also who hires someone before they agree on a salary? Says right there: "Arnold Blake". -- Simen

Re: Mission impossible

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote: On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh wrote: struct S { static void func(T)(uint a, T t) { } static void func() { } } Your mission, Jim, should you choose to accept it, is this: Get a pointer

Re: =void in struct definition

On Monday, 9 April 2018 at 11:06:50 UTC, Shachar Shemesh wrote: struct S { int a; int[5000] arr = void; } void func() { S s; } During the s initialization, the entire "S" area is initialized, including the member arr which we asked to be = void. Is this a bug? https://issues.dlang.o

Re: /^(?:([^:\/?#]+):)?(?:\/\/((?:(([^:@]*)(?::([^:@]*))?)?@)?([^:\/?#]*)(?::(\d*))?))?((((?:[^?#\/]*\/)*)([^?#]*))(?:\?([^#]*))?(?:#(.*))?)/, [your code here]

On Friday, 6 April 2018 at 13:10:07 UTC, jason wrote: what is this? Line noise.

Re: DIP in making: ProtoObject

On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu wrote: On 04/04/2018 09:18 AM, 12345swordy wrote: No attempts to make class deallocation @nogc attribute friendly? This is a major PIA for me. The current attempts at this involve various workarounds (See automem library for examp

Re: __has_side_effects

On Saturday, 31 March 2018 at 19:18:24 UTC, Shachar Shemesh wrote: struct S { int a; void func(int b) pure { // For some strange reason, this is not considered a pure violation. a+=b; } } It's the exact equivalent of this code: void func(ref S s, int b) pure { S.a += b; }

Re: #dbugfix Issue 16486 200$

On Saturday, 31 March 2018 at 13:34:18 UTC, Kagamin wrote: On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote: Ah that is an interesting bug which further demonstrates that templates are a tricky thing :) Basically you cannot _generally_ proof that one template just forwards to another

Re: #dbugfix Issue 16486 200$

On Friday, 30 March 2018 at 15:49:30 UTC, jmh530 wrote: On Friday, 30 March 2018 at 15:21:26 UTC, jmh530 wrote: [snip] Doesn't extend to multiple template parameters that well... import std.traits : TemplateOf; struct TestType(T, U) {} alias TestAlias(T) = TestType!(T, int); template testF

Re: #dbugfix Issue 16486 200$

On Friday, 30 March 2018 at 17:10:22 UTC, 9il wrote: On Friday, 30 March 2018 at 13:56:45 UTC, Stefan Koch wrote: On Friday, 30 March 2018 at 06:11:22 UTC, 9il wrote: [1] https://issues.dlang.org/show_bug.cgi?id=16486 Solving this may be possible for special cases but in the general case is

Re: newCTFE Status March 2018

On Saturday, 31 March 2018 at 08:29:22 UTC, Stefan Koch wrote: On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter wrote: Ok, so it will take 90% of the total to get to the remaining 10%. So it will be ready for 2028 :-) huh that's not quite right The approx time I worked on it is 1.6

Re: Must ranges support `r1 = r2;`?

On Saturday, 24 March 2018 at 22:36:55 UTC, Simen Kjærås wrote: struct RefRange(R) { R* innerRange; this(R* innerRange) { this.innerRange = innerRange; } void popFront() { innerRange.popFront(); } @property auto front() { return innerRange.front;

Re: Must ranges support `r1 = r2;`?

On Saturday, 24 March 2018 at 21:44:35 UTC, ag0aep6g wrote: Long version: ("std.range and std.algorithm can't handle refRange"). Short version: With two `std.range.RefRange`s, `r1 = r2;` does not what other Phobos code expects. Question is: Wh

Re: #dbugfix 17592

On Thursday, 22 March 2018 at 14:48:04 UTC, 12345swordy wrote: On Thursday, 22 March 2018 at 02:35:41 UTC, Adam D. Ruppe wrote: On Thursday, 22 March 2018 at 01:55:48 UTC, 12345swordy wrote: Are you suggesting that we need runtime version of system/user attributes? We already have that in a s

Re: #dbugfix 17592

On Wednesday, 21 March 2018 at 08:49:11 UTC, Mike Franklin wrote: I think `rt_finalize` can be made `@nogc` in the runtime. And this is where you're wrong. Consider this: class A { @nogc ~this() {} } class B : A { ~this() {} } A a = new B(); destroy(a); // Is this @nogc? Essential

Re: #dbugfix Issue 5710

On Tuesday, 20 March 2018 at 00:00:22 UTC, ciechowoj wrote: Digging out and old yet important issue. +1 - my favorite issue!

Re: rvalue types

On Monday, 12 March 2018 at 18:00:02 UTC, Steven Schveighoffer wrote: So if I could rephrase to make sure I understand: An rvalue type is one that you can never assign to a variable. As soon as you try to "store" it somewhere, it becomes a new type that is returned by its "get" function. In t

Re: rvalue types

On Monday, 12 March 2018 at 18:04:07 UTC, Shachar Shemesh wrote: On 12/03/18 16:31, Simen Kjærås wrote: The main idea behind rvalue types and their name, is that they are types that can only ever be rvalues, not by convention, but through the type system. How do you prevent creating a named i

Re: rvalue types

On Monday, 12 March 2018 at 16:51:06 UTC, H. S. Teoh wrote: I suspect the current language already supports this, or is 90% of the way there and just needs some small concessions on syntax. For example, today you can already make opBinary() return something other than the parent type, and use

Re: rvalue types

On Monday, 12 March 2018 at 14:19:17 UTC, Shachar Shemesh wrote: I'll just point out that the C++ name for this is "Proxy classes". Maybe, for the sake of reducing confusion, it might be a good idea to adopt that. The main idea behind rvalue types and their name, is that they are types that c

rvalue types

There's been a discussion[0] over in D.learn about a library-only implementation of properties. One of the ideas mentioned there is rvalue types - types that automatically decay into a different type when passed to a function or assigned to a variable. They are useful for property wrappers like

Re: Making recursively-defined traits iterative using `static foreach`

On Saturday, 10 March 2018 at 13:30:18 UTC, Nordlöw wrote: On Saturday, 10 March 2018 at 09:47:55 UTC, Nordlöw wrote: Now that we have `static foreach` I just realized we can start... My recent definition now looks like template allSameTypeIterative(V...) // TODO restrict `V` to types only {

Re: Why does this not compile?

On Tuesday, 6 March 2018 at 13:56:30 UTC, Steven Schveighoffer wrote: On 3/6/18 8:42 AM, Simen Kjærås wrote: unittest {     int i = 0;     struct S {     int n;     void fun() const {     i++;     }     }     const S s;     assert(i == 0);     s.fun();     assert(i

Re: Why does this not compile?

On Tuesday, 6 March 2018 at 12:00:43 UTC, Steven Schveighoffer wrote: On 3/6/18 6:21 AM, Simen Kjærås wrote: On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote: void main() {     struct S {     uint value;     ~this() {     }     }     const S a = S(12);     S b = a;

Re: Why does this not compile?

On Tuesday, 6 March 2018 at 10:03:54 UTC, Shachar Shemesh wrote: void main() { struct S { uint value; ~this() { } } const S a = S(12); S b = a; } test.d(10): Error: cannot implicitly convert expression a of type const(S) to S Looks like a bug to me -

Re: How to stringify a template instantiation expression?

On Thursday, 1 March 2018 at 16:46:30 UTC, Yuxuan Shui wrote: On Wednesday, 28 February 2018 at 15:49:25 UTC, aliak wrote: On Wednesday, 28 February 2018 at 15:09:56 UTC, Yuxuan Shui wrote: For a template instantiation expression like A!(B, C!(D, E)), I want to get a string "A!(B, C!(D, E))", b

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

On Tuesday, 27 February 2018 at 09:58:00 UTC, bauss wrote: On Tuesday, 27 February 2018 at 09:47:51 UTC, Stefan Koch wrote: On Tuesday, 27 February 2018 at 09:23:19 UTC, bauss wrote: On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote: see rationale in https://issues.dlang.org/sh

Re: Can this be done? Defining type as in this Scala sample code

On Monday, 26 February 2018 at 15:43:54 UTC, Bienlein wrote: object Scratch extends App { // compiles: val list = List(1, 2.4, 5) val sum = list.sum println(sum) // does not compile: val list2 = List(1, 2.4, 5, "123") val sum2 = list2.sum println(sum2) } There's nothing in

Re: PackedAliasSeq?

On Thursday, 22 February 2018 at 19:26:54 UTC, Andrei Alexandrescu wrote: template PackedAliasSeq!(T...) { alias expand = AliasSeq!T; } I started playing around with this a few days ago, and came up with another interesting abstraction - NamedPack: alias foo = NamedPack!("Type", int,

Re: how to propagate computed type during CTFE?

On Friday, 23 February 2018 at 00:54:34 UTC, Timothee Cour wrote: in example below, how do I propagate RET (or even `typeof(a)`) to the result value of `inferType`? does this need a language change to allow this? No can do. Consider what would happen if you added put(1); inside fun - what sh

Re: Somewhat OT: defining algebras in D

On Friday, 9 February 2018 at 15:45:11 UTC, Amorphorious wrote: On Friday, 9 February 2018 at 02:40:06 UTC, Nick Sabalausky (Abscissa) wrote: Well, that's the difference between a formal library package release vs sharing a working proof of concept jotted down to pass time ;) Yes, but he can

Somewhat OT: defining algebras in D

So I was bored in a meeting and decided to implement a generic template for defining complex numbers, dual numbers, quaternions and many other possible algebras by simply defining a set of rules and the components on which they act: alias quaternion = Algebra!( float, "1,i,j,k

Re: !Alert! dlang.org SSL Error

On Tuesday, 6 February 2018 at 14:32:41 UTC, Jakub Łabaj wrote: On Tuesday, 6 February 2018 at 14:05:46 UTC, Seb wrote: Vladimir already did so an hour ago. Though his web presence is blank for me at the moment: https://www.janknepper.com Works for me again. I also had this happen yesterda

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 12:13:22 UTC, Guillaume Piolat wrote: On Tuesday, 6 February 2018 at 09:02:46 UTC, Simen Kjærås wrote: On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: What do you think? It's already possible, with only very slightly worse aesthetics: [Good stuff]

Re: Language Idea #6892: in array ops, enable mixing slices and random access ranges

On Tuesday, 6 February 2018 at 02:14:35 UTC, Meta wrote: What do you think? It's already possible, with only very slightly worse aesthetics: [Good stuff] We can do better than that, though: import std.range, std.array, std.algorithm; struct Vec(Range) if (isInputRange!Range) { Range rn

Re: Annoyance with new integer promotion deprecations

On Monday, 5 February 2018 at 21:21:47 UTC, H. S. Teoh wrote: On Mon, Feb 05, 2018 at 09:20:16PM +, Nick Sabalausky via Digitalmars-d wrote: But still, I thought we had value range propagation rules to avoid this sort of nonsense when possible (such as the example above)? VRP doesn't help

Re: Implementing tail-const in D

On Thursday, 25 January 2018 at 21:33:10 UTC, Simen Kjærås wrote: On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote: In fact, if the standard implementation of opHeadMutable is basically the same across all types (or most types), it could even be provided as a mixin template in the

Re: Implementing tail-const in D

On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote: I like this idea quite much, actually, in spite of the lack of support for implicit conversions, which is a loss (but as you said, we can't support that without breaking a lot of existing stuff or introducing massive changes that a

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 14:55:39 UTC, Simen Kjærås wrote: auto map(alias fn, R)(R r) if (isInputRange!(HeadMutable!R)) { // Pass head-mutable versions to MapResult. return MapResult!(fn, HeadMutable!R)(headMutable(r)); } Another thing that I didn't think of when writing the above

Re: Implementing tail-const in D

On Wednesday, 24 January 2018 at 11:21:59 UTC, Nick Treleaven wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Unqual is the standard way today to get a head-mutable version of something. For dynamic arrays, static arrays, pointers and value types, including structs witho

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 14:17:26 UTC, Andrea Fontana wrote: On Tuesday, 23 January 2018 at 12:39:12 UTC, Simen Kjærås wrote: On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required

Re: Implementing tail-const in D

On Tuesday, 23 January 2018 at 12:12:42 UTC, Nicholas Wilson wrote: On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Questions: Is a DIP required for this? A DIP is required for language changes. So yes. No language changes are proposed - this is all library code. -- Simen

Implementing tail-const in D

Since tail-const (more correctly called head-mutable) was mentioned here lately (in the 'I closed a very old bug!'[1] thread), I've been racking my brain to figure out what needs doing to make a viable solution. Unqual is the standard way today to get a head-mutable version of something. For

Re: Tail Const (Was: I closed a very old bug!)

On Thursday, 18 January 2018 at 09:15:04 UTC, Simen Kjærås wrote: At any rate, this is a topic for a DIP. So, a few more thoughts on this: Arrays and pointers automatically decay to their Unqual'ed variants when passed to a templated function. AAs do not, which makes sense given their refere

Re: __ARGS__ : allow access to (stringified) arguments, as C's `#arg` macro

On Friday, 19 January 2018 at 08:51:00 UTC, Jacob Carlborg wrote: Not sure I understand this feature. Is it something like: auto foo = 3; auto bar = 4; log(foo, bar); Would print? main.d:3 foo=3 main.d:3 bar=4 If that's the case then this seems like yet another hack because we don't have AST

Re: __traits(documentation, X)

On Wednesday, 17 January 2018 at 22:15:08 UTC, H. S. Teoh wrote: 2) Self-checking programs: import std.algorithm; static assert(import(__FILE__).canFind("\n/**"), "Dude, why did you remove the ddoc comment?!"); /** Remove this comment to get a compile err

Tail Const (Was: I closed a very old bug!)

On Wednesday, 17 January 2018 at 10:36:44 UTC, Jonathan M Davis wrote: D is quite useable without tail-const, but without it, ranges and const can't be used together. The solution that most of us have taken is basically to give up on const. Having tail-const would be better, but implementing it

Re: __traits(documentation, X)

On Wednesday, 17 January 2018 at 16:52:40 UTC, Steven Schveighoffer wrote: The charter of comments is to NOT affect code, ever. They can be used to affect other systems, such as the ddoc generator, ide hints, etc., but you can be sure (?) that comments won't change code. I think this is an im

Re: I closed a very old bug!

On Tuesday, 16 January 2018 at 22:01:43 UTC, Mark wrote: On Tuesday, 16 January 2018 at 19:45:06 UTC, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=255 I think it would be great to reduce the median age of open issues, and the median longevity of closed issues. I'm in ta

Re: Proposed Phobos equivalent of wcswidth()

On Monday, 15 January 2018 at 13:34:09 UTC, Jack Stouffer wrote: std.utf.displayWidth +1 -- Simen

Re: Unable to run D program on mac system when using dependency.

On Wednesday, 10 January 2018 at 12:44:01 UTC, Harbeer Kadian wrote: I am pretty new to D language. I am working on existing code developed by others. Previous developers were using linux environment to build and run the D Application. I am trying to do the same in MAC as it is my local environ

Re: Alias Vs. Enum?

On Sunday, 7 January 2018 at 03:52:53 UTC, Stefan Koch wrote: The compiler can only alias to symbols and not to values. therefore enum was chosen for manifest constants. That alias can bind to values in template-parameters is useful but not exactly consistent :) Not only that, but alias can b

Re: Multiple inheritance D entry on rosettacode.org

On Wednesday, 20 December 2017 at 19:11:19 UTC, Jean-Louis Leroy wrote: See http://rosettacode.org/wiki/Inheritance/Multiple#D I feel that the entry is incomplete. I am a supported of full-fledged MI, à la Common Lisp or C++, and the argument that interfaces solve most problems that MI solves,

Re: Replacing std.math raw pointer arithmetic with a union type

On Wednesday, 17 May 2017 at 03:02:02 UTC, tsbockman wrote: std.math contains a lot of raw pointer arithmetic for accessing the various bit fields of floating-point values (see https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code has several nearly-identical copies, manually speciali

Re: Fixing opEquals and opCmp

On Saturday, 13 May 2017 at 14:17:24 UTC, H. S. Teoh wrote: Andrei specifically stated before that opCmp may model a partial order, i.e., returning 0 may indicate "not comparable" rather than "equal". And this is why opEquals is necessary: to distinguish between "not comparable" and "equal".

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

On 2014-04-28 21:06, Walter Bright via Digitalmars-d wrote: On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote: I believe Steven expects things to work this way: module bar; extern(C++, foo) void func(); module prog; import bar; void main() { foo.func(); // Calls bar.func (or

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

On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote: On 4/28/2014 7:27 AM, Steven Schveighoffer wrote: Consider this code: module foo; void func() {} module bar; extern(C) func(); module prog; import foo; import bar; void main() { func(); // error foo.func(); // ok bar.