On 3/29/20 9:02 PM, H. S. Teoh wrote:
> On Sun, Mar 29, 2020 at 07:01:18PM +0000, Mathias Lang via Digitalmars-d wrote:
>> On Sunday, 29 March 2020 at 18:24:33 UTC, IGotD- wrote:
> [...]
>>> If we going to go to D3, then we need a proper project plan so that
>>> people know what they are supposed to implement. That means that
>>> someone needs to decide what to implement.
> [...]
>> The problem is not whether or not we need to come up with a list of
>> things to implement. The problem is, who will implement it ? And the
>> answer has always been, those who care, those who will use it, or
>> Walter.
> [...]
> 
> Yes, herein lies the rub.  There is no shortage of good ideas and
> opinions in this forum, but when it comes time to actually write the
> code and make it work, the enthusiasm seems to evaporate and the
> manpower is nowhere to be found.  Grand plans have been drawn up in the
> past, and countless lists of tasks that need to be done.  None of that
> has made much of a difference.  The difference has mostly been made by a
> number of silent contributors who don't speak up much, but do most of
> the real work behind the scenes and make things tick.
> 
> This is the curse of the volunteer project: nobody gets paid so when
> they're told what to do rather than making their own choice about what
> to do, they just walk away.  We can invent grand plans all we like, but
> until there's somebody passionate enough to actually put in the hard
> work to implement said grand plan, nothing will actually happen.
> 
> Instead, what tends to get done is the itch that somebody wants to
> scratch, that doesn't always match what others want.

Good points, but I think that we are currently suffering from a different problem -- people want to, and do, implement these things, only to be told no, sorry we want it but we can't use it, because it breaks things. I listed several things that have been implemented but were rejected (or merged and reverted). Some of them even by the creator and BDFL of the language. Some other things are just wholesale changes to the library that implementing them is just not going to happen without some significant buy-in from the community and leaders.

On top of that, people who may want to implement things are gun shy after seeing language changes get shot down left and right.

Yes, we also still need leadership to approve and agree that X should be implemented. But right now, even they say X should be implemented, but we just can't without breaking "everything".

What we need is a place for that answer to be yes instead. If not D3.0, I don't know what is the correct path for such things.

-Steve

On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
> On 3/28/20 1:09 PM, Denis Feklushkin wrote:

>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
>
> I would say no, for 2 reasons. One, this is basically renaming without benefit.

My second proposal is remove auto casting to int while calculations:
int8 * int8 == int16 (not int32)

Sometimes it causes unncessary casts. Intuitively it seems that it is uneconomical and possibly spoils superscalarity.

Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)

On 30/03/2020 6:51 PM, Denis Feklushkin wrote:
> On Sunday, 29 March 2020 at 13:34:44 UTC, Steven Schveighoffer wrote:
>> On 3/28/20 1:09 PM, Denis Feklushkin wrote:
> 
>>> int -> int32
>>> ulong -> uint64
>>> float -> float32
>>> double -> float64
>>> byte -> octet
>>
>> I would say no, for 2 reasons. One, this is basically renaming without benefit.
> 
> My second proposal is remove auto casting to int while calculations:
> int8 * int8 == int16 (not int32)
> 
> Sometimes it causes unncessary casts. Intuitively it seems that it is uneconomical and possibly spoils superscalarity.
> 
> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)

C integer promotion is a feature, it is not going anywhere.

On Sunday, 29 March 2020 at 13:35:35 UTC, Francesco Mecca wrote:

> What about phobos and the druntime then?
> If we switch to D3 it makes sense to shrink the druntime to a smaller one that doesn't bring all the weight of unused features.

druntime is good enough

Now I am slowly working on detaching it from libc as much as possible. And also, to reduce its size, it can be compiled statically and only with necessary functions.

While this is not implemented in the master branch, but problems with this work is not expected (haha)

On Monday, 30 March 2020 at 05:54:55 UTC, rikki cattermole wrote:

>> My second proposal is remove auto casting to int while calculations:
>> int8 * int8 == int16 (not int32)
>> 
>> Sometimes it causes unncessary casts. Intuitively it seems that it is uneconomical and possibly spoils superscalarity.
>> 
>> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
>
> C integer promotion is a feature, it is not going anywhere.

I do not understand its usefulness.
But I sure that if this proposal will be accepted existing code will be broken silently and this means this can only be implemented in D3.

On Monday, 30 March 2020 at 05:54:55 UTC, rikki cattermole wrote:

>> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
>
> C integer promotion is a feature, it is not going anywhere.

I remember exactly that this has already been discussed here and your point of view won. I can’t just find. Well, okay.

On Sunday, 29 March 2020 at 23:27:06 UTC, Meta wrote:
> On Sunday, 29 March 2020 at 12:00:20 UTC, Paulo Pinto wrote:
>> On Sunday, 29 March 2020 at 09:47:15 UTC, Russel Winder wrote:
>>> On Sat, 2020-03-28 at 11:01 +0000, Paulo Pinto via Digitalmars-d wrote:
>>>> […]
>>>> 
>>>> Groovy isn't properly a good exemple.
>>>
>>> I see no reason why it isn't, it is an evolving language following the semantc versioning model.
>>>
>>>> If it wasn't for Gradle and its use in Android, it would be long gone and forgotten.
>>>
>>> In you opinion. The evidence I see is that Groovy has more traction in Java sites than is immediately apparent. Clearly Kotlin is challenging the role of Groovy in many respects, but Groovy is still used by many orgsanisation fro dynamic programing. The analogy is where C++ codebases use Python or Lua.
>>>
>>>> And even there, there is a big pressure to replace it with Kotlin, in what regards Android build infrastructure.
>>>
>>> Kotlin rather than Groovy is the language of choice on the Android platform these days certainly, but there are a lot of JVM installation out there using Java, Kotlin, and Groovy – not to mention Scala, Clojure, etc. – all going along happily. Yes there are a lot of those installations that will only use Java.
>>>
>>>> So is the fate of any guest language until the main platform language catches up.
>>>
>>> Java can never catch up with Groovy, whereas is can catch up with Kotlin. Kotlin is the guest language you are talking of for most Java installation, not Groovy. Statis Groovy may be a dead thing, but Dynamic Groovy is far from dead.
>>
>> The times that Groovy made any headlines in German Java conferences or local JUGs are long gone, I wonder where Groovy is being used above a single digit usage market share on the Java platform.
>
> IBM Security, one of the largest cybersecurity companies in the world. The most widely used enterprise-level SIEM (by quite a wide margin) uses Groovy extensively for its testing framework.

The same IBM that introduced Beanshell for scripting Java beans, once upon time used JTcl for Websphere scripting until version 6, replaced it with jython on Websphere 6 and now just offers JMX MBeans on Liberty?

Yep, definitely a guarantee of longevity regarding IBM's usage of JVM guest languages.

On 30/03/2020 7:12 PM, Denis Feklushkin wrote:
> On Monday, 30 March 2020 at 05:54:55 UTC, rikki cattermole wrote:
> 
>>> Perhaps this from those ancient times when compatibility D with C was declared at source level? (Or am I confusing and there was no such period?)
>>
>> C integer promotion is a feature, it is not going anywhere.
> 
> I remember exactly that this has already been discussed here and your point of view won. I can’t just find. Well, okay.

Short answer: it is too late to change it.

Long answer: all options are fairly opinionated and arbitrary.

There is no right answer.

Whatever option you go with, you will have cases where you will want to cast to a more appropriate type.

With the C promotion rules at least, most C family developers should be able to understand them and they will "just work" including when they are porting code from other languages.

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>
> Other languages evolve much quicker than D, but break things only in major updates. D seems to "sort of" break things, there's always a risk in every release. We try to be conservative, but we have this horrible mix of deciding some features can break things, while others are not allowed to, and there's no clear guide as to which breakage fits in which category.
>
> If we went to a more regular major release schedule, and decided for a roadmap for each major release what features would be included, it would allow much better planning, and much more defensible breakage of code. If you know that your code will only compile with D2.x, and you're fine with that, then great, don't upgrade to D3.x. If you desperately want a feature, you may have to upgrade to D3.x, but once you get there, you know your code is going to build for a while.
>
> We could also not plan for many major releases, but at least move to D3 for some major TLC to the language that is held back to prevent breakage.
>
> I work occasionally with Swift, and they move very fast, and break a lot of stuff, but only in major versions. It's a bit fast for my taste, but it seems to work for them. And they get to fix issues that languages like C++ might have been stuck with forever.
>
> The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.
>
> I just wanted to throw it out as a discussion point. We spend an awful lot of newsgroup server bytes debating things that to me seem obvious, but have legitimate downsides for not breaking them in a "stable" language.
>
> -Steve

Some things I'd like to see in d3 that can't be done without breaking D:
- Fixing attribute syntax: @safe vs pure (why not @pure?) or @safe vs @nogc (why no-prefix?). It would be nice to have #pure #safe #gc and their negative. And leave @ for UDA. So we have no need to reserve any keyword.
- Remove unfinished things. For ex.: multiple alias this, @property, real, cfloat, ucent, etc...
- Fixing range, autodecoder, ...
- Removing old modules from phobos
- Adding some features like string interpolation, static initialization of AAs

Andrea

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> [...]

58. Be "tooling-friendly" this time