On 6/27/2016 8:14 AM, Robert burner Schadek wrote:
> On Sunday, 26 June 2016 at 22:38:54 UTC, Walter Bright wrote:
>> It's a wiki, feel free to add it.
>
> I have to say that reply really makes me angry. I created that list so Andrei
> and you have an easy to find spot where you can write down tasks so people can
> work on them. You did not disagree with the list at the time, and didn't
> disagree so far. I really think it is clear that these are two list that you two
> are maintaining, how else should anybody know what work is pre-approved and
> where D is going.
>
> I think I'm not asking too much here, if I ask you to decide if you want to
> maintain that list or if you want to delete it. The current limbo state is just
> making things worse.

Sorry to have offended you, I worded things badly. Thank you for making the list. It's just that I'm feeling a bit overwhelmed at the moment with trying to get things done and being asked to do more every day, and I'd like to delegate.

On Monday, 27 June 2016 at 19:33:45 UTC, Walter Bright wrote:
> Sorry to have offended you, I worded things badly. Thank you for making the list. It's just that I'm feeling a bit overwhelmed at the moment with trying to get things done and being asked to do more every day, and I'd like to delegate.

Don't sweat it. I just replied in the heat of the moment and thereby violated my personal 24 hour no reply rule.

Back to topic, I think this list will save you and Andrei work in the long run. I mean if the list is up to date, you do not have to repeat yourself. Well expect "read the list!" ;-)

On 06/28/2016 05:34 PM, Robert burner Schadek wrote:
> On Monday, 27 June 2016 at 19:33:45 UTC, Walter Bright wrote:
>> Sorry to have offended you, I worded things badly. Thank you for
>> making the list. It's just that I'm feeling a bit overwhelmed at the
>> moment with trying to get things done and being asked to do more every
>> day, and I'd like to delegate.
>
> Don't sweat it. I just replied in the heat of the moment and thereby
> violated my personal 24 hour no reply rule.
>
> Back to topic, I think this list will save you and Andrei work in the
> long run. I mean if the list is up to date, you do not have to repeat
> yourself. Well expect "read the list!" ;-)

That's a great rule. I should add that the official "things to do" list is the vision document. We don't need a separate list. -- Andrei

On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
> On 6/25/2016 3:44 PM, Walter Bright wrote:
>> 4. Add @safe to the unittest
>
> A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.

What about existing tests that are marked @trusted?

Atila

On Wednesday, 29 June 2016 at 17:25:31 UTC, Atila Neves wrote:
> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
>> On 6/25/2016 3:44 PM, Walter Bright wrote:
>>> 4. Add @safe to the unittest
>>
>> A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.
>
> What about existing tests that are marked @trusted?
>
> Atila

Maybe I'm missing something, but...
What's the purpose of a @trusted unittest? If it's safe, mark it @safe. If it's not, you gain nothing from marking it @trusted, given that it will not be called by @safe code (it will not be called in general). @trusting a top-level function is useless IMHO...

On Wednesday, 29 June 2016 at 17:33:18 UTC, Lodovico Giaretta wrote:
> On Wednesday, 29 June 2016 at 17:25:31 UTC, Atila Neves wrote:
>> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
>>> On 6/25/2016 3:44 PM, Walter Bright wrote:
>>>> 4. Add @safe to the unittest
>>>
>>> A unittest that is deliberately unsafe should be annotated with @system. Meaning that any un-annotated unittest needs corrective action one way or the other.
>>
>> What about existing tests that are marked @trusted?
>>
>> Atila
>
> Maybe I'm missing something, but...
> What's the purpose of a @trusted unittest? If it's safe, mark it @safe. If it's not, you gain nothing from marking it @trusted, given that it will not be called by @safe code (it will not be called in general). @trusting a top-level function is useless IMHO...

I don't think there's any point either, I just thought I'd ask before changing them to @system.

Atila

On 6/29/2016 10:25 AM, Atila Neves wrote:
> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
>> On 6/25/2016 3:44 PM, Walter Bright wrote:
>>> 4. Add @safe to the unittest
>>
>> A unittest that is deliberately unsafe should be annotated with @system.
>> Meaning that any un-annotated unittest needs corrective action one way or the
>> other.
>
> What about existing tests that are marked @trusted?

Marking a unittest as @trusted seems pointless.

On 6/29/16 4:57 PM, Walter Bright wrote:
> On 6/29/2016 10:25 AM, Atila Neves wrote:
>> On Saturday, 25 June 2016 at 22:56:12 UTC, Walter Bright wrote:
>>> On 6/25/2016 3:44 PM, Walter Bright wrote:
>>>> 4. Add @safe to the unittest
>>>
>>> A unittest that is deliberately unsafe should be annotated with @system.
>>> Meaning that any un-annotated unittest needs corrective action one
>>> way or the
>>> other.
>>
>> What about existing tests that are marked @trusted?
>
> Marking a unittest as @trusted seems pointless.
>

I would further say -- if you see a @trusted unit test, whoever wrote it doesn't understand the point of @trusted. Be sure and check the code it is testing too, and file bugs if appropriate.

-Steve

On Sunday, 26 June 2016 at 13:13:01 UTC, Robert burner Schadek wrote:
> It would be awesome if you would create that process model in the wiki and at it to your action list http://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List
>
> So it does not get lost and people can find it.

Could you elaborate on list option 9 "create a module that enables code to be run on GPU." Wouldn't the Derelict OpenCL bindings satisfy that need?

On 6/30/2016 4:09 AM, Steven Schveighoffer wrote:
> I would further say -- if you see a @trusted unit test, whoever wrote it doesn't
> understand the point of @trusted. Be sure and check the code it is testing too,
> and file bugs if appropriate.

I agree. Using @trusted properly turns out to have some surprising subtleties, but this one is pretty much a no-brainer.