On 9/17/20 2:50 PM, H. S. Teoh wrote:
> On Thu, Sep 17, 2020 at 02:41:09PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 9/17/20 1:56 PM, Avrina wrote:
>>> `reduce` does support static arrays btw.
>>
>> Somebody shoot me.
> 
> BANG.
> 
> :-P
> 
> IMO, we should deprecate static array support on .reduce. (Not that it
> really matters anymore to me; .reduce has the wrong parameter order from
> the days before UFCS, and has been supplanted by .fold.  I sure hope
> .fold isn't stupid enough to accept static arrays...)
Looks like it does: https://run.dlang.io/is/GiStHq

On Thursday, September 17, 2020 2:07:35 PM MDT H. S. Teoh via Digitalmars-d wrote:
> That bug has been filed for years, I wish somebody would take it up and push it in. :-/  That has been a bad idea for years and yet it still persists.
>
>   https://issues.dlang.org/show_bug.cgi?id=15932

I've brought it up to Walter before. As I understand it, his opinion is that scope solves the problem. And while I agree that it helps, I still think that it would be better to just disallow the implict conversion entirely and require that it be explicit. That being said, I don't expect that we'll ever see such a change in D2, much as I think that it would be worth it.

- Jonathan M Davis

On Thu, Sep 17, 2020 at 04:19:38PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/17/20 2:50 PM, H. S. Teoh wrote:
[...]
> > IMO, we should deprecate static array support on .reduce. (Not that it really matters anymore to me; .reduce has the wrong parameter order from the days before UFCS, and has been supplanted by .fold. I sure hope .fold isn't stupid enough to accept static arrays...)
> Looks like it does: https://run.dlang.io/is/GiStHq

And a glance at the code reveals why: .fold uses .reduce as its implementation.

So yeah, we should deprecate static array support on .reduce.


T

-- 
What's an anagram of "BANACH-TARSKI"?  BANACH-TARSKI BANACH-TARSKI.

On Thu, Sep 17, 2020 at 02:23:43PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, September 17, 2020 2:07:35 PM MDT H. S. Teoh via Digitalmars-d wrote:
> > That bug has been filed for years, I wish somebody would take it up and push it in. :-/  That has been a bad idea for years and yet it still persists.
> >
> >   https://issues.dlang.org/show_bug.cgi?id=15932
> 
> I've brought it up to Walter before. As I understand it, his opinion is that scope solves the problem.

No, it doesn't solve the problem.  It fixes the *symptom*, but the underlying problem persists.


> And while I agree that it helps, I still think that it would be better to just disallow the implict conversion entirely and require that it be explicit. That being said, I don't expect that we'll ever see such a change in D2, much as I think that it would be worth it.
[...]

Yeah, implicit is bad.  I used to be a fan of implicit things, because of the convenience... but more and more, with more experience, I'm starting to be convinced that explicit is always better -- for readability and maintainability. Too many layers of implicit things, and the code becomes obscure, hard to read, or easy to *wrongly* read, and consequently fragile.


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

On 2020-09-17 18:18, Andrei Alexandrescu wrote:

> Does this pass the laugh test? How can one explain a colleague "yep, here are the conditions under which you can iterate over an object in the D language".
Won't you have the same problem with `foreach`? It supports even more ways to iterate.

-- 
/Jacob Carlborg

On 2020-09-17 19:41, Seb wrote:

> The only way for this to ever happen is if we start with it. One function at a time.
> I suggest simply creating a new repository and starting from zero.
> Apart from the clear mental divide and separation, this has the added advantage that we can just keep druntime and phobos as is and work on a new combined "base" library. There are a few others like being able to immediately ship it via dub or being able to use GitHub's features (issues, projects, roadmaps, ...).

I suggest to have some for of plan. If we start just throwing in stuff it most likely is not going to be any better than the current version.

-- 
/Jacob Carlborg

On 9/18/20 10:26 AM, Jacob Carlborg wrote:
> On 2020-09-17 19:41, Seb wrote:
> 
>> The only way for this to ever happen is if we start with it. One function at a time.
>> I suggest simply creating a new repository and starting from zero.
>> Apart from the clear mental divide and separation, this has the added advantage that we can just keep druntime and phobos as is and work on a new combined "base" library. There are a few others like being able to immediately ship it via dub or being able to use GitHub's features (issues, projects, roadmaps, ...).
> 
> I suggest to have some for of plan. If we start just throwing in stuff it most likely is not going to be any better than the current version.

At DConf 2019 I discussed a new version of std separately with a handful of folks. Two things that all discussions had in common:

1. They were incredibly excited by the perspective.

2. They had wildly different (and in parts conflicting) views on what that should look like.

On Thursday, 17 September 2020 at 21:03:08 UTC, H. S. Teoh wrote:

> Yeah, implicit is bad.  I used to be a fan of implicit things, because of the convenience... but more and more, with more experience, I'm starting to be convinced that explicit is always better -- for readability and maintainability. Too many layers of implicit things, and the code becomes obscure, hard to read, or easy to *wrongly* read, and consequently fragile.
>
>
> T

By implicit I am assuming your talking about c++ here correct? I consider that language to implement implicit conversions poorly. Functions should opt-in implicit conversions, not opt-out.

The main case for it is writing:

T t = a;

Instead of:

T t = (t)a

That the main benefit of implicit conversion that we should be focusing on.

On Fri, Sep 18, 2020 at 10:40:08AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> At DConf 2019 I discussed a new version of std separately with a handful of folks. Two things that all discussions had in common:
> 
> 1. They were incredibly excited by the perspective.
> 
> 2. They had wildly different (and in parts conflicting) views on what
> that should look like.

So where do we go from here?  What about we make itemized lists of the wildly different views and see if we can find some common ground that we can build on?


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall

On Fri, Sep 18, 2020 at 02:55:39PM +0000, 12345swordy via Digitalmars-d wrote:
> On Thursday, 17 September 2020 at 21:03:08 UTC, H. S. Teoh wrote:
> 
> > Yeah, implicit is bad.  I used to be a fan of implicit things, because of the convenience... but more and more, with more experience, I'm starting to be convinced that explicit is always better -- for readability and maintainability. Too many layers of implicit things, and the code becomes obscure, hard to read, or easy to *wrongly* read, and consequently fragile.
[...]
> By implicit I am assuming your talking about c++ here correct?

I'm speaking in general.  It applies to any language, really.


[...]
> The main case for it is writing:
> 
> T t = a;
> 
> Instead of:
> 
> T t = (t)a
> 
> That the main benefit of implicit conversion that we should be focusing on.

Just write:

	auto t = T(a);

Mission accomplished, no need for implicit conversion, and it's clear exactly what's going on.

In non-trivial cases, I know it's convenient not to have to write T(a) all the time, but really, it's better to write it out explicitly so that future readers of the code (i.e., you after 3 months :-D) know exactly what conversions are taking place and how.  When there are too many implicit conversions, the code may look better superficially, but actually it may be hiding inefficient implicit conversions, or it may look like it's doing something but it's actually doing something else because of the implicit conversions.  It's more inconvenient to write things out explicitly, but in the long run it's better.


T

-- 
Computers aren't intelligent; they only think they are.