I've packaged my reusable extensions to Phobos at

https://github.com/nordlow/phobos-next

PRs are very welcome.

There are lots of goodies here. Some of them should probably be moved to standard Phobos. I currently have lots of other D things to do, but you guys are welcome to try to integrate them into Phobos.

Enjoy or Destroy!

On Saturday, 9 April 2016 at 18:25:54 UTC, Nordlöw wrote:
> I've packaged my reusable extensions to Phobos at
>
> https://github.com/nordlow/phobos-next
>
> PRs are very welcome.
>
> There are lots of goodies here. Some of them should probably be moved to standard Phobos. I currently have lots of other D things to do, but you guys are welcome to try to integrate them into Phobos.
>
> Enjoy or Destroy!

Not all functions have documentation comments.
But most have unittests. You can add empty documentation comments before each unittest to make them appear in docs as examples of usage.

On 09.04.2016 20:25, Nordlöw wrote:
> https://github.com/nordlow/phobos-next
[...]
> Enjoy or Destroy!

Pet peeve of mine: Many of your @trusted functions are unsafe. @trusted functions must be memory-safe. At the very least the public ones must be.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/random_ex.d#L145>:

This @trusted variant of randInPlace calls another overload on the generic element type. That call is possibly unsafe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/random_ex.d#L176>:

Similarly, this @trusted variant calls randInPlace on the generic type B.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/dbg.d#L34>:

`@trusted:` makes everything below it @trusted. Aside from trustedPureDebugCall, it doesn't look those templates are supposed to be @trusted. trustedPureDebugCall breaks the @trusted promise, too, of course. But at least it says so in its name.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/array_ex.d#L92>:

This makes `clear` @trusted, practically making `free` @trusted. Being able to call `free` on arbitrary pointers is the opposite of memory-safe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/array_ex.d#L355>:

Trusting an arbitrary range. Range primitives may be unsafe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/array_ex.d#L542>,
<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/array_ex.d#L827>,
<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/array_ex.d#L835>:

Probably more bad `@trusted`s. Didn't check thoroughly, though.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L88>,
<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L144>:

Changing arbitrary bits in arbitrary types is the opposite of memory-safe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/assert_ex.d#L14>:

`@trusted:` again, followed by a bunch of templates, all of which seem to possibly execute arbitrary, potentially unsafe code provided by the caller.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/skip_ex.d#L164>:

Probably another bad `@trusted`.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/ties.d#L88>:

Calling an arbitrary delegate is the opposite of memory-safe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/algorithm_ex.d#L295>:

T.opAssign may be unsafe.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/algorithm_ex.d#L325>,
<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/algorithm_ex.d#L352>,
<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/algorithm_ex.d#L415>:

Probably more bad `@trusted`s.

--

<https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/algorithm_ex.d#L857>:

Operator overloading can make comparisons unsafe.

--

I suggest to put comments on all @trusted attributes, listing what parts of the implementation prevent the @safe attribute, and explaining how memory-safety is ensured despite that.

On Saturday, 9 April 2016 at 18:25:54 UTC, Nordlöw wrote:
> I've packaged my reusable extensions to Phobos at
>
> https://github.com/nordlow/phobos-next

Also at http://code.dlang.org/packages/phobos-next

On Saturday, 9 April 2016 at 23:49:14 UTC, ag0aep6g wrote:
> <https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L88>,
> <https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L144>:
>
> Changing arbitrary bits in arbitrary types is the opposite of memory-safe.

These operate only on integer types thanks to isIntegral template constraint. Are you saying I need to limit to machine types u?int{8,16,32,64,12} to not include BigInt? If so is there a trait for this?

On Sunday, 10 April 2016 at 20:24:41 UTC, Nordlöw wrote:
> These operate only on integer types thanks to isIntegral template constraint. Are you saying I need to limit to machine types u?int{8,16,32,64,12} to not include BigInt? If so is there a trait for this?

Further, perhaps we could/should do range checking on the bit index parameter(s).

On Sunday, 10 April 2016 at 20:24:41 UTC, Nordlöw wrote:
> On Saturday, 9 April 2016 at 23:49:14 UTC, ag0aep6g wrote:
>> <https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L88>,
>> <https://github.com/nordlow/phobos-next/blob/596da6eb534926ee0d94e9f711a169e58026688e/src/bitop_ex.d#L144>:
>>
>> Changing arbitrary bits in arbitrary types is the opposite of memory-safe.
>
> These operate only on integer types thanks to isIntegral template constraint. Are you saying I need to limit to machine types u?int{8,16,32,64,12} to not include BigInt? If so is there a trait for this?

No, these are the overloads for non-integer T. The constraint says `!(isIntegral!T)`. The integer overloads are above the ones I linked, respectively.

On Sunday, 10 April 2016 at 20:54:31 UTC, ag0aep6g wrote:
> No, these are the overloads for non-integer T. The constraint says `!(isIntegral!T)`. The integer overloads are above the ones I linked, respectively.

Ok. Thanks. Fixed.