Re: ndslice: feature deprecation voting / discussion
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
Re: ndslice: feature deprecation voting / discussion
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
Re: ndslice: feature deprecation voting / discussion
On Monday, 3 October 2016 at 03:04:31 UTC, Manu wrote: On 3 October 2016 at 00:02, Ilya Yaroshenko via Digitalmars-d 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.
Re: ndslice: feature deprecation voting / discussion
On 3 October 2016 at 00:02, Ilya Yaroshenko via Digitalmars-d 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)
Re: ndslice: feature deprecation voting / discussion
On 3 October 2016 at 01:00, Andrei Alexandrescu via Digitalmars-d 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.
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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...)
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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
Re: ndslice: feature deprecation voting / discussion
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.
Re: ndslice: feature deprecation voting / discussion
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
Re: ndslice: feature deprecation voting / discussion
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
ndslice: feature deprecation voting / discussion
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
