Jump to page: 1 2
Thread overview
ndslice: feature deprecation voting / discussion
Oct 02, 2016
Ilya Yaroshenko
Oct 02, 2016
rikki cattermole
Oct 02, 2016
Ilya Yaroshenko
Oct 02, 2016
Ilya Yaroshenko
Oct 03, 2016
Manu
Oct 02, 2016
John Colvin
Oct 02, 2016
Ilya Yaroshenko
Oct 02, 2016
John Colvin
Oct 02, 2016
Ilya Yaroshenko
Oct 02, 2016
John Colvin
Oct 02, 2016
jmh530
Oct 02, 2016
Dennis Ritchie
Oct 03, 2016
Manu
Oct 03, 2016
Ilya Yaroshenko
October 02, 2016
Timothee Cour proposed to deprecate arguments without [ ... ] that represent shape .

  auto a0=iota(3*4).sliced(3,4); // proposal:deprecate
  auto a1=iota(3*4).sliced([3,4]);
  auto a2=iotaSlice(3,4); // proposal:deprecate
  auto a3=iotaSlice([3,4]);
  auto a6=slice!int(3,4);// proposal:deprecate
  auto a4=slice!int([3,4]);

  ... the same for blocks, windows, ... etc.

Mir Issue: https://github.com/libmir/mir/issues/337

Current Yes: Timothee Cour, John Colvin
Current No : Ilya Yaroshenko, Relja Ljubobratovic

If you want to see the code please use Phobos code (not Mir). Template bloat was significantly reduced in https://github.com/dlang/phobos/pull/4823.

Ilya
October 03, 2016
On 03/10/2016 3:02 AM, Ilya Yaroshenko wrote:
> Timothee Cour proposed to deprecate arguments without [ ... ] that
> represent shape .
>
>   auto a0=iota(3*4).sliced(3,4); // proposal:deprecate
>   auto a1=iota(3*4).sliced([3,4]);
>   auto a2=iotaSlice(3,4); // proposal:deprecate
>   auto a3=iotaSlice([3,4]);
>   auto a6=slice!int(3,4);// proposal:deprecate
>   auto a4=slice!int([3,4]);
>
>   ... the same for blocks, windows, ... etc.
>
> Mir Issue: https://github.com/libmir/mir/issues/337
>
> Current Yes: Timothee Cour, John Colvin
> Current No : Ilya Yaroshenko, Relja Ljubobratovic
>
> If you want to see the code please use Phobos code (not Mir). Template
> bloat was significantly reduced in
> https://github.com/dlang/phobos/pull/4823.
>
> Ilya

Will dmd store void func(int[]), func([1, 2]) the array onto the stack?
If it doesn't then T[] v... would be better which will accept both.

It also won't increase template bloat.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

October 02, 2016
On 10/02/2016 10:02 AM, Ilya Yaroshenko wrote:
> Timothee Cour proposed to deprecate arguments without [ ... ] that
> represent shape .
>
>   auto a0=iota(3*4).sliced(3,4); // proposal:deprecate
>   auto a1=iota(3*4).sliced([3,4]);
>   auto a2=iotaSlice(3,4); // proposal:deprecate
>   auto a3=iotaSlice([3,4]);
>   auto a6=slice!int(3,4);// proposal:deprecate
>   auto a4=slice!int([3,4]);
>
>   ... the same for blocks, windows, ... etc.
>
> Mir Issue: https://github.com/libmir/mir/issues/337
>
> Current Yes: Timothee Cour, John Colvin
> Current No : Ilya Yaroshenko, Relja Ljubobratovic
>
> If you want to see the code please use Phobos code (not Mir). Template
> bloat was significantly reduced in
> https://github.com/dlang/phobos/pull/4823.

My general thinking here is that if we improve compiler technology to avoid template bloat, that would "lift all boats" i.e. make everybody's life better. So that would be preferable (to the extent possible) to requiring user-level idioms. -- Andrei

October 02, 2016
On Sunday, 2 October 2016 at 14:02:31 UTC, Ilya Yaroshenko wrote:
> Timothee Cour proposed to deprecate arguments without [ ... ] that represent shape .
>
>   auto a0=iota(3*4).sliced(3,4); // proposal:deprecate
>   auto a1=iota(3*4).sliced([3,4]);
>   auto a2=iotaSlice(3,4); // proposal:deprecate
>   auto a3=iotaSlice([3,4]);
>   auto a6=slice!int(3,4);// proposal:deprecate
>   auto a4=slice!int([3,4]);
>
>   ... the same for blocks, windows, ... etc.
>
> Mir Issue: https://github.com/libmir/mir/issues/337
>
> Current Yes: Timothee Cour, John Colvin
> Current No : Ilya Yaroshenko, Relja Ljubobratovic
>
> If you want to see the code please use Phobos code (not Mir). Template bloat was significantly reduced in https://github.com/dlang/phobos/pull/4823.
>
> Ilya

I'm not that fussed about template bloat, but future API flexibility seems important.
October 02, 2016
On Sunday, 2 October 2016 at 15:26:00 UTC, John Colvin wrote:
> On Sunday, 2 October 2016 at 14:02:31 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> I'm not that fussed about template bloat, but future API flexibility seems important.

Current API has not flexibility issue related to shape. At least i can not find it
October 02, 2016
On Sunday, 2 October 2016 at 14:23:02 UTC, rikki cattermole wrote:
> On 03/10/2016 3:02 AM, Ilya Yaroshenko wrote:
>> [...]
>
> Will dmd store void func(int[]), func([1, 2]) the array onto the stack?
> If it doesn't then T[] v... would be better which will accept both.
>
> It also won't increase template bloat.
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

(size_t v)(T[N] v...) accepts both without memory allocation. This is used in current implementation.
October 02, 2016
On Sunday, 2 October 2016 at 15:31:35 UTC, Ilya Yaroshenko wrote:
> On Sunday, 2 October 2016 at 14:23:02 UTC, rikki cattermole wrote:
>> On 03/10/2016 3:02 AM, Ilya Yaroshenko wrote:
>>> [...]
>>
>> Will dmd store void func(int[]), func([1, 2]) the array onto the stack?
>> If it doesn't then T[] v... would be better which will accept both.
>>
>> It also won't increase template bloat.
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>
> (size_t v)(T[N] v...) accepts both without memory allocation. This is used in current implementation.

EDIT: (size_t N)(size_t[N] v...)
October 02, 2016
On Sunday, 2 October 2016 at 15:26:00 UTC, John Colvin wrote:
>
> I'm not that fussed about template bloat, but future API flexibility seems important.

Wouldn't it be more flexible to allow both ways?

If D can handle the case without brackets without any issue, why force it?

In Matlab, writing ones(2, 2) produces a 2x2 matrix of ones.
In numpy, I would write np.ones((2, 2))

I find it annoying that in numpy I have to constantly remember to put in the second set of parentheses. This idea is basically forcing the same issue into ndslice. I think it's a bad idea.

October 02, 2016
On Sunday, 2 October 2016 at 16:36:14 UTC, jmh530 wrote:
> On Sunday, 2 October 2016 at 15:26:00 UTC, John Colvin wrote:
>>
>> I'm not that fussed about template bloat, but future API flexibility seems important.
>
> Wouldn't it be more flexible to allow both ways?
>
> If D can handle the case without brackets without any issue, why force it?
>
> In Matlab, writing ones(2, 2) produces a 2x2 matrix of ones.
> In numpy, I would write np.ones((2, 2))
>
> I find it annoying that in numpy I have to constantly remember to put in the second set of parentheses. This idea is basically forcing the same issue into ndslice. I think it's a bad idea.

+1
October 02, 2016
On Sunday, 2 October 2016 at 15:29:45 UTC, Ilya Yaroshenko wrote:
> On Sunday, 2 October 2016 at 15:26:00 UTC, John Colvin wrote:
>> On Sunday, 2 October 2016 at 14:02:31 UTC, Ilya Yaroshenko wrote:
>>> [...]
>>
>> I'm not that fussed about template bloat, but future API flexibility seems important.
>
> Current API has not flexibility issue related to shape. At least i can not find it

I was thinking of what you would do if you wanted to add an extra argument to a variation function. It's much easier if it's just a normal static array argument.
« First   ‹ Prev
1 2