Jump to page: 1 28  
Page
Thread overview
What features of D you would not miss?
Sep 15
Dukc
Sep 15
Dukc
Sep 15
JN
Sep 15
bauss
Sep 15
IGotD-
Sep 15
ryuukk_
Sep 15
Dukc
Sep 15
bauss
Sep 15
ryuukk_
Sep 15
IGotD-
Sep 15
ryuukk_
Sep 15
jmh530
Sep 15
bauss
Sep 15
jmh530
Sep 15
bauss
Sep 15
bauss
Sep 15
ryuukk_
Sep 16
xxd
Sep 15
Sergey
Sep 15
bauss
Sep 15
zjh
Sep 15
Dennis
Sep 15
bauss
Sep 15
bauss
Sep 16
bauss
Sep 16
bauss
Sep 15
Dennis
Sep 16
RazvanN
Sep 15
Kagamin
Sep 16
Luhrel
Sep 16
Luhrel
Sep 17
Ogi
Sep 17
Dennis
Sep 20
Ogi
Sep 20
bauss
Sep 20
Ogi
Sep 20
Abdulhaq
Sep 20
Ogi
Sep 20
Abdulhaq
Sep 17
0xEAB
Sep 18
Sergey
September 15

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

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

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

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

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

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

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

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

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

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