On Friday, 18 September 2020 at 15:22:58 UTC, H. S. Teoh wrote:
> 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.

Not true, other languages implement implicit conversions in different ways. Seriously what languages are you referring here?

> [...]
>> 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.

You are making assertions that you can write:
          auto t = T(a);

That is not necessarily the case.

>... future readers of the code know exactly what conversions are taking
> place and how.
We have a solution to that already it called comments.

>  When there are too many implicit conversions,

What exactly do you mean by this? The implicit conversions that I have in mind is that implicit conversions happen once and only once per statement.

> the code may look better superficially, but actually it may be hiding inefficient implicit conversions,

What do you mean by "Inefficient" here? That sounds like an implementation issue rather than a casting issue.

> or it may look like it's doing something but it's actually doing something else because of the implicit conversions.

That why comments are there for.

On Friday, 18 September 2020 at 16:21:47 UTC, 12345swordy wrote:
> On Friday, 18 September 2020 at 15:22:58 UTC, H. S. Teoh wrote:
>> On Fri, Sep 18, 2020 at 02:55:39PM +0000, 12345swordy via
[...]
>>> By implicit I am assuming your talking about c++ here correct?
>>
>> I'm speaking in general.  It applies to any language, really.
>
> Not true, other languages implement implicit conversions in different ways. Seriously what languages are you referring here?
[...]

Any language.  Implicit conversions have a tendency of reducing code maintainability or quality.

Here's a small sampling of issues that may be encountered:

1) Scala: https://www.rallyhealth.com/coding/implicit-implications-part-2-implicit-conversions

    Quote: "In fact, Scala has deemed that implicit conversions are so dangerous, they require you to import scala.language.implicitConversions to use them"

2) C++: https://docs.microsoft.com/en-us/cpp/cpp/type-conversions-and-type-safety-modern-cpp?view=vs-2019

    Quote: "However, even if your program compiles without warnings, it still may contain code that leads to implicit type conversions that produce incorrect results."

3) Javascript: https://blog.acolyer.org/2015/08/04/the-good-the-bad-and-the-ugly-an-empirical-study-of-implicit-type-conversions-in-javascript/

    Quote: "A small but non-negligible percentage (1.15%) of all type coercions are potentially harmful. Future language designs or restricted versions of JavaScript may want to forbid them."

4) SQL: https://towardsdatascience.com/how-not-to-kill-your-sql-server-performance-with-implicit-conversion-e754ac2eb134?gi=86749251fcf1

    Quote: "In order to resolve inconsistencies between data types, SQL Server must put additional effort and consume more resources. Thus, performance will suffer, leading to inefficient usage of indexes and extensive usage of CPU."

5) C#: https://netvignettes.wordpress.com/2011/04/24/implicit-conversion-operators-are-bad/

    Quote: "... certain markers that indicate to me that the coder in question is inexperienced and needs more guidance. / One such marker is the use of implicit conversion operators on reference types."

This is just a random sampling I got from Google. There are many more. It also corroborates my own experience working with C, C++, Java, and D.  In spite of repeated complaints over the years, I have to say I'm glad that Walter stuck to his guns and refused to add implicit constructors to D.  Nevertheless, D still has implicit conversions, some of which seemed like a good idea at the time, but eventually it leads to trouble, one prime example being alias this. (I still use alias this, mind you, but more and more I'm beginning to realize it's not such a good idea. It's convenient, for sure, but leads to hard-to-understand code. Not to mention it interacts poorly with generic code, because you can never be 100% sure exactly what type you're getting out of it.)


--T

On 9/18/20 11:02 AM, H. S. Teoh wrote:
> 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?

A strong leader needs to emerge. A vague list-driven community effort is doomed to shuffle the rubble once again with a 2% increase in overall quality of the library.

A good leader would have a powerful overall vision and at least one big specific idea.

On Friday, 18 September 2020 at 16:47:40 UTC, H. S. Teoh wrote:
> On Friday, 18 September 2020 at 16:21:47 UTC, 12345swordy wrote:
>> On Friday, 18 September 2020 at 15:22:58 UTC, H. S. Teoh wrote:
>>> On Fri, Sep 18, 2020 at 02:55:39PM +0000, 12345swordy via
> [...]
>>>> By implicit I am assuming your talking about c++ here correct?
>>>
>>> I'm speaking in general.  It applies to any language, really.
>>
>> Not true, other languages implement implicit conversions in different ways. Seriously what languages are you referring here?
> [...]
>
> Any language.  Implicit conversions have a tendency of reducing code maintainability or quality.

I noticed that you had ignore my other questions. Stop making weasel words by saying "Implicit conversions have a tendency of reducing code maintainability or quality." without specifying how!

> Here's a small sampling of issues that may be encountered:
You can make the same kind of statement regarding the goto feature.


> This is just a random sampling I got from Google.

https://www.logicallyfallacious.com/logicalfallacies/Biased-Sample-Fallacy

 (I still use alias this, mind
> you, but more and more I'm beginning to realize it's not such a good idea. It's convenient, for sure, but leads to hard-to-understand code. Not to mention it interacts poorly with generic code, because you can never be 100% sure exactly what type you're getting out of it.)
>
>
> --T

The issue with alias this is that it introduces the multiple inheritance promblem, not that introduces implicit conversion.

On Fri, Sep 18, 2020 at 02:02:17PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/18/20 11:02 AM, H. S. Teoh wrote:
> > 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:
[...]
> > 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?
> 
> A strong leader needs to emerge. A vague list-driven community effort is doomed to shuffle the rubble once again with a 2% increase in overall quality of the library.
> 
> A good leader would have a powerful overall vision and at least one big specific idea.

So who will this person be?

If there are no candidates, then I'm just going to bow out, since it will just be another vacuous hypothetical discussion that leads to no action and no change.

<offtopic>
Perhaps this is the underlying problem with D and its community.  We're
all looking for revolutionary change, neglecting that sometimes progress
is made incrementally.  If we reject the incremental while waiting for
the revolutionary that never arrives, that's just letting the perfect
become the enemy of the good.  This would explain a lot of our problems.
Like revolutionary features that are not quite finished, features that
have gaping holes for years, and the like.  We have an awesome language
that has huge potential, but it's being let down by rough edges and lack
of polish, because good is not good enough for us, and the perfect
hasn't arrived yet, and nobody knows when (or if) it will.
</offtopic>


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

On Friday, 18 September 2020 at 16:21:47 UTC, 12345swordy wrote:
> On Friday, 18 September 2020 at 15:22:58 UTC, H. S. Teoh wrote:
>> On Fri, Sep 18, 2020 at 02:55:39PM +0000, 12345swordy via Digitalmars-d wrote:
>>  When there are too many implicit conversions,
>
> What exactly do you mean by this? The implicit conversions that I have in mind is that implicit conversions happen once and only once per statement.

No. Generally speaking they happen (or at least are tried) once per binary expression (that includes assignments).

In "a = b(c + d);" you have 3:
1. return type of `b(c+d)` to `a` type
2. `c` to `d` type (or the opposite)
3. `c + d` to the type of `c` first param.

But those are essential. It's not a question of too much / efficiency.
A backend cant do its job without them and a frontend that doesn't do them automatically means that the language is a joke.

On Thursday, 17 September 2020 at 16:18:18 UTC, Andrei Alexandrescu wrote:
> The implementation of each in std.algorithm.iteration sets out a lofty goal: whatever can be iterated, must be iterated with each.
>
> Problem is, there are way too many things that can be iterated in D and too many ways to iterate them. This leads to a veritable gallop of checks:
>
>  [...SNIP...]
>
> Too much!
>

Agree! There is a greater sense in which too much effort is placed on some end-user stuff within the base language. An example is the `std.csv` package, even Julia - a language specifically designed for scientific/technical/data science computing does not have a csv reader in its standard library (it has DelimitedFiles which does something different - single type file read), instead it has a separate CSV package. The D language allows you to parse a typical XSV file very easily, so instead of aiming specifically at CSV files, just have better curated and documented a general I/O library.

I think a lot of people attracted to D are looking to fish, not to be given fish. If the D community has a smaller standard library footprint, hiving off certain things to DUB, it should free up resources for better curation and documentation.

On Sunday, 20 September 2020 at 12:08:05 UTC, data pulverizer wrote:

> ...There is a greater sense in which too much effort is placed on some end-user stuff within the base language ...

Correction, I meant within the standard library

On 9/18/20 2:24 PM, H. S. Teoh wrote:
> On Fri, Sep 18, 2020 at 02:02:17PM -0400, Andrei Alexandrescu via Digitalmars-d wrote:
>> On 9/18/20 11:02 AM, H. S. Teoh wrote:
>>> 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:
> [...]
>>> 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?
>>
>> A strong leader needs to emerge. A vague list-driven community effort
>> is doomed to shuffle the rubble once again with a 2% increase in
>> overall quality of the library.
>>
>> A good leader would have a powerful overall vision and at least one
>> big specific idea.
> 
> So who will this person be?
> 
> If there are no candidates, then I'm just going to bow out, since it
> will just be another vacuous hypothetical discussion that leads to no
> action and no change.
> 
> <offtopic>
> Perhaps this is the underlying problem with D and its community.  We're
> all looking for revolutionary change, neglecting that sometimes progress
> is made incrementally.  If we reject the incremental while waiting for
> the revolutionary that never arrives, that's just letting the perfect
> become the enemy of the good.  This would explain a lot of our problems.
> Like revolutionary features that are not quite finished, features that
> have gaping holes for years, and the like.  We have an awesome language
> that has huge potential, but it's being let down by rough edges and lack
> of polish, because good is not good enough for us, and the perfect
> hasn't arrived yet, and nobody knows when (or if) it will.
> </offtopic>

Fair point, and I wanted to write a related post as well. Just FWIW, Walter and Steve Schveighoffer are discussing how to version phobos appropriately. That is important work that qualifies as incremental.