digitalmars.D - ndslice: feature deprecation voting / discussion

Ilya Yaroshenko (16/16) Oct 02 2016 Timothee Cour proposed to deprecate arguments without [ ... ]

rikki cattermole (7/23) Oct 02 2016 Will dmd store void func(int[]), func([1, 2]) the array onto the stack?

Ilya Yaroshenko (3/14) Oct 02 2016 (size_t v)(T[N] v...) accepts both without memory allocation.

Ilya Yaroshenko (2/20) Oct 02 2016 EDIT: (size_t N)(size_t[N] v...)

Andrei Alexandrescu (5/20) Oct 02 2016 My general thinking here is that if we improve compiler technology to

Manu via Digitalmars-d (16/42) Oct 02 2016 Ah, the 'sufficiently high-quality compiler' unicorn. It's been a

Andrei Alexandrescu (4/6) Oct 03 2016 For this particular matter it's somewhat of a solved problem in C++. Is

John Colvin (3/19) Oct 02 2016 I'm not that fussed about template bloat, but future API

Ilya Yaroshenko (3/8) Oct 02 2016 Current API has not flexibility issue related to shape. At least

John Colvin (4/13) Oct 02 2016 I was thinking of what you would do if you wanted to add an extra

Ilya Yaroshenko (2/17) Oct 02 2016 slice!double([3, 4], 0.0) works now.

John Colvin (6/24) Oct 02 2016 I suppose there's always this option: support varidics for

jmh530 (9/11) Oct 02 2016 Wouldn't it be more flexible to allow both ways?

Dennis Ritchie (2/14) Oct 02 2016 +1
Relja Ljubobratovic (2/10) Oct 03 2016 I feel the same way. +1 here

Manu via Digitalmars-d (6/21) Oct 02 2016 Why?

Ilya Yaroshenko (4/12) Oct 02 2016 Current API looks like this foo(size_t N)(size_t[N] shape...). I

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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

Oct 02 2016

rikki cattermole <rikki cattermole.co.nz> writes:

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

Oct 02 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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.

Oct 02 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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...)

Oct 02 2016

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

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

Oct 02 2016

Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:

On 3 October 2016 at 01:00, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 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

Ah, the 'sufficiently high-quality compiler' unicorn. It's been a
legend in C++ for at least 20 years that I've been looking... I have
developed and shipped something like 17 games in the meantime waiting
for compilers to not suck. In many cases they are better today, but in
many cases they still suck. It's a dangerous proposition to have
engineers expect the compiler works properly and discourage good
(practical) practise or understanding codegen because "the compiler
'should' do that for you" ;) ... They are a particular (dangerous)
kind of engineer that appears in the wild, and I often dismiss job
applicants on this basis.
My take on this comment, don't EVER say "the compiler 'should' do this
thing for you" until *all compilers* do.

Regarding the OP... I'm nervous about this change. Why do it? If it
doesn't inline for any reason, it's quite a blow on windows.

Oct 02 2016

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 10/02/2016 11:01 PM, Manu via Digitalmars-d wrote:
 Ah, the 'sufficiently high-quality compiler' unicorn. It's been a
 legend in C++ for at least 20 years that I've been looking...

For this particular matter it's somewhat of a solved problem in C++. Is 
it your perception as well that template bloat in C++ seems to have 
discussed a lot more in the past than in recent times? -- Andrei

Oct 03 2016

John Colvin <john.loughran.colvin gmail.com> writes:

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.

Oct 02 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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

Oct 02 2016

John Colvin <john.loughran.colvin gmail.com> writes:

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.

Oct 02 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

On Sunday, 2 October 2016 at 17:11:55 UTC, John Colvin wrote:
 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.

slice!double([3, 4], 0.0) works now.

Oct 02 2016

John Colvin <john.loughran.colvin gmail.com> writes:

On Sunday, 2 October 2016 at 17:33:49 UTC, Ilya Yaroshenko wrote:
 On Sunday, 2 October 2016 at 17:11:55 UTC, John Colvin wrote:
 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.

 slice!double([3, 4], 0.0) works now.

I suppose there's always this option: support  varidics for 
simple cases and restrict extra args to the static array 
overloads.

I still think it's better to have one way and stick with it. 
Simpler, less possibility for misunderstanding.

Oct 02 2016

jmh530 <john.michael.hall gmail.com> writes:

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.

Oct 02 2016

Dennis Ritchie <dennis.ritchie mail.ru> writes:

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

Oct 02 2016

Relja Ljubobratovic <ljubobratovic.relja gmail.com> writes:

On Sunday, 2 October 2016 at 16:36:14 UTC, jmh530 wrote:
 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.

I feel the same way. +1 here

Oct 03 2016

Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:

On 3 October 2016 at 00:02, Ilya Yaroshenko via Digitalmars-d
<digitalmars-d puremagic.com> 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


Why?

Isn't this what f(T[] shape...) template syntax is for? Ie, supports
both syntax with the same instantiation?
(https://dlang.org/spec/function.html#typesafe_variadic_functions)

Oct 02 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

On Monday, 3 October 2016 at 03:04:31 UTC, Manu wrote:
 On 3 October 2016 at 00:02, Ilya Yaroshenko via Digitalmars-d 
 <digitalmars-d puremagic.com> wrote:
 [...]


 Why?

 Isn't this what f(T[] shape...) template syntax is for? Ie, 
 supports
 both syntax with the same instantiation?
 (https://dlang.org/spec/function.html#typesafe_variadic_functions)

Current API looks like this foo(size_t N)(size_t[N] shape...). I 
am voting No. So, probably your question should be forwarded to 
Timothee Cour and John Colvin.

Oct 02 2016

D Programming

C/C++ Programming

Other

digitalmars.D - ndslice: feature deprecation voting / discussion