Jump to page: 1 28  
Page
Thread overview
What features of D you would not miss?
Sep 15, 2022
Dukc
Sep 15, 2022
Dukc
Sep 15, 2022
JN
Sep 15, 2022
bauss
Sep 15, 2022
IGotD-
Sep 15, 2022
ryuukk_
Sep 15, 2022
Dukc
Sep 15, 2022
bauss
Sep 15, 2022
ryuukk_
Sep 15, 2022
IGotD-
Sep 15, 2022
ryuukk_
Sep 16, 2022
Walter Bright
Sep 15, 2022
jmh530
Sep 15, 2022
bauss
Sep 15, 2022
jmh530
Sep 15, 2022
bauss
Sep 15, 2022
bauss
Sep 15, 2022
H. S. Teoh
Sep 15, 2022
ryuukk_
Sep 15, 2022
Paul Backus
Sep 16, 2022
xxd
Sep 16, 2022
Walter Bright
Sep 16, 2022
Mike James
Sep 15, 2022
Sergey
Sep 15, 2022
bauss
Sep 15, 2022
Adam D Ruppe
Sep 15, 2022
Max Samukha
Sep 15, 2022
zjh
Sep 15, 2022
Dennis
Sep 15, 2022
bauss
Sep 15, 2022
bauss
Sep 16, 2022
Walter Bright
Sep 16, 2022
bauss
Sep 16, 2022
bauss
Sep 15, 2022
Nick Treleaven
Sep 15, 2022
Dennis
Sep 15, 2022
Max Samukha
Sep 15, 2022
Timon Gehr
Sep 16, 2022
RazvanN
Sep 15, 2022
Kagamin
Sep 16, 2022
Guillaume Piolat
Sep 16, 2022
Guillaume Piolat
Sep 16, 2022
Luhrel
Sep 16, 2022
H. S. Teoh
Sep 16, 2022
Luhrel
Sep 17, 2022
Ogi
Sep 17, 2022
Dennis
Sep 18, 2022
Paul Backus
Sep 18, 2022
Timon Gehr
Sep 18, 2022
rikki cattermole
Sep 20, 2022
Ogi
Sep 20, 2022
bauss
Sep 20, 2022
Ogi
Sep 20, 2022
max haughton
Sep 20, 2022
Abdulhaq
Sep 20, 2022
Ogi
Sep 20, 2022
Quirin Schroll
Sep 20, 2022
Abdulhaq
Sep 17, 2022
0xEAB
Sep 20, 2022
Quirin Schroll
Sep 18, 2022
Nicholas Wilson
Sep 18, 2022
Timon Gehr
Sep 18, 2022
Walter Bright
Sep 18, 2022
Walter Bright
Sep 18, 2022
Nicholas Wilson
Sep 18, 2022
Walter Bright
Sep 18, 2022
Nicholas Wilson
Sep 18, 2022
Timon Gehr
Sep 18, 2022
Nicholas Wilson
Sep 19, 2022
Timon Gehr
Sep 18, 2022
Timon Gehr
Sep 18, 2022
Sergey
September 15, 2022

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one.

What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.


Quoting direct replies to the question from the original thread.

On Wednesday, 14 September 2022 at 13:30:46 UTC, Adam D Ruppe wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

ImportC, -betterC, @nogc, nothrow, @live. These things don't even work on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit.

To a lesser extent, @safe and dip1000 can go too.

On Wednesday, 14 September 2022 at 14:28:40 UTC, Steven Schveighoffer wrote:

>

On 9/14/22 1:58 AM, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

There's a difference between "not worth adding" and "not worth keeping". Removing features needs a very high bar to make sense. Adding features also needs a high bar, considering that it's more difficult to remove later than it is to not add it.

That being said, if binary literals weren't in the language, I'd be fine adding them. They don't cost anything, and add a way to write code that is clearer in some cases.

If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd want to remove. D's features are pretty nice.

-Steve

On Wednesday, 14 September 2022 at 15:51:17 UTC, Nick Treleaven wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

Template constraints. Horrible error messages (though better than they were) and confusing to work out which overload matches. They make documentation complicated. Just use static if and static assert instead to solve all these problems.

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.

Personally I'd agree with Walter that hex literals are usually better and the possiblity for a library solution makes binary literals even less necessary. I wouldn't personally miss binary literals. But all the contrary feedback in that thread convinced me that many would, so it'd be a bad removal especially considering how simple it is for the compiler/spec.

Other ideas:

  • All the stuff that is deprecated already, according to the removal schelude.

  • @live. It's a good experimental concept for a future DIP to build on, but does not currently justify it's complexity in a real project.

  • @property, as said in another thread. well maybe not removed, but changed to a no-op. With a deprecation period, warnings given for uses that depend on current semantics of it.

  • lazy, if DIP1033 is awaken and accepted. With a deprecation period of course.

  • Old alias syntax alias originalName Alias. I'd prefer alias this to also use the new syntax. Again, deprecation period needed.

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.

I'd remove templates, but since you mention breakages... in such case I'd say contracts, finalizers and possibly exceptions.

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

-release

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.

None, that don't get in my way. If a feature is opt-in then if you don't use them there is no big deal for me.

What is a big deal for me are features that don't work or are half finished.

Example of this are shared, @safe, @live (not a comprehensive memory management feature) and probably ImportC.

I'm starting to come to the conclusion that the D project is broken and must be revamped, that is D3. I think that D should be forked with new people and management. Hopefully this enables more focus in the project and that D can evolve in a more usable language that isn't full of holes and half thought out features.

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

This is a good question, but would quickly derail the original thread from it's topic, so I decided to start a new one.

What features could be removed from D if it were up to you? Please consider the breakage that would result from the removal, don't settle on thinking what shouldn't have been added in the first place.


Quoting direct replies to the question from the original thread.

On Wednesday, 14 September 2022 at 13:30:46 UTC, Adam D Ruppe wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

ImportC, -betterC, @nogc, nothrow, @live. These things don't even work on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit.

To a lesser extent, @safe and dip1000 can go too.

On Wednesday, 14 September 2022 at 14:28:40 UTC, Steven Schveighoffer wrote:

>

On 9/14/22 1:58 AM, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

There's a difference between "not worth adding" and "not worth keeping". Removing features needs a very high bar to make sense. Adding features also needs a high bar, considering that it's more difficult to remove later than it is to not add it.

That being said, if binary literals weren't in the language, I'd be fine adding them. They don't cost anything, and add a way to write code that is clearer in some cases.

If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd want to remove. D's features are pretty nice.

-Steve

On Wednesday, 14 September 2022 at 15:51:17 UTC, Nick Treleaven wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:

>

But it doesn't disprove the fact that sometimes, hex digits aren't as clear.

Does sometimes justify a language feature, when there are other ways?

People often complain that D has too many features. What features would you say are not worth it?

Template constraints. Horrible error messages (though better than they were) and confusing to work out which overload matches. They make documentation complicated. Just use static if and static assert instead to solve all these problems.

  • Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be Java or C#

  • Exception Handling (taking inspiration from Swift would be interesting)

  • @property apparently, i forgot this was a thing until i saw the post yesterday

  • enum, replace this and make better enum with pattern matching and .Enum

  • byte, short, int, long, give me (u8, u16, u32, u64, * = either nothing or int)

September 15, 2022

On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:

>
  • Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be Java or C#

  • Exception Handling (taking inspiration from Swift would be interesting)

  • @property apparently, i forgot this was a thing until i saw the post yesterday

  • enum, replace this and make better enum with pattern matching and .Enum

  • byte, short, int, long, give me (u8, u16, u32, u64, * = either nothing or int)

Remember, I asked to consider what you would remove considering backwards compatibility. You can't be serious about removing all of these, it'd break literally everything.

September 15, 2022

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:
On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

ImportC, -betterC, @nogc, nothrow, @live. These things don't even work on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit.

If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd want to remove. D's features are pretty nice.

-Steve

I’m pretty surprised that people mentioned betterC.. I expected improvements and development of that part.
AFAIK it is the easiest way to use D in WebAssembly, also a lot of great and high performant libs (like mir) working in betterC mode only..

September 15, 2022

On Thursday, 15 September 2022 at 11:15:21 UTC, Sergey wrote:

>

On Thursday, 15 September 2022 at 08:40:22 UTC, Dukc wrote:

>

On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote (on the thread about binary literals):

>

On 9/13/2022 7:56 PM, Steven Schveighoffer wrote:
On Wednesday, 14 September 2022 at 05:58:53 UTC, Walter Bright wrote:

>

People often complain that D has too many features. What features would you say are not worth it?

ImportC, -betterC, @nogc, nothrow, @live. These things don't even work on their own terms, and they continue to have additional downstream effects over several parts of D and the ecosystem. Massive complication for little benefit.

If I had to pick at gunpoint an established language feature to remove, it would be betterC. But I can't see any features I'd want to remove. D's features are pretty nice.

-Steve

I’m pretty surprised that people mentioned betterC.. I expected improvements and development of that part.
AFAIK it is the easiest way to use D in WebAssembly, also a lot of great and high performant libs (like mir) working in betterC mode only..

I considered writing betterC, but it arguably has a place. I think the problem is that it is a subset and it shouldn't be. It should just be possible to be barebone without resorting to a subset of the language.

September 15, 2022

On Thursday, 15 September 2022 at 11:11:47 UTC, Dukc wrote:

>

On Thursday, 15 September 2022 at 10:50:11 UTC, ryuukk_ wrote:

>
  • Class as reference type without the *, it should have been like Go since day 1, so no confusion instead of trying to be Java or C#

  • Exception Handling (taking inspiration from Swift would be interesting)

  • @property apparently, i forgot this was a thing until i saw the post yesterday

  • enum, replace this and make better enum with pattern matching and .Enum

  • byte, short, int, long, give me (u8, u16, u32, u64, * = either nothing or int)

Remember, I asked to consider what you would remove considering backwards compatibility. You can't be serious about removing all of these, it'd break literally everything.

alias uint = u32;

« First   ‹ Prev
1 2 3 4 5 6 7 8