On Sunday, 5 February 2023 at 22:40:09 UTC, ProtectAndHide wrote:
>
> ..


module test;

import std;

static final class Algo
{
    @disable this();

    static this()
    {
        Message =  "Hello!";
    }

    static:

    string Message;

    void drawLine() {};
}

void main()
{
    Algo foo1 = null; // the compiler should not allow you to declare a variable of static type
    Algo[] foo2 = null; //  the compiler should not allow you to declare an array with elements of static type
    List[Algo] foo3; // the compiler should not allow you to use static types as type arguments

    writeln(foo1);
    writeln(foo2);
    writeln(foo3);
}

void Method1(Algo x) {} //  the compiler should not allow you to use static types as parameters

Algo Method2() { return null; } // the compiler should not allow you to use static types as return types

struct List {}

On 2/5/23 02:57, thebluepandabear wrote:

> When dealing with contexts, or for when you want a clear context in your
> codebase, namespaces can be a life saver

Can you give an example of a D problem that namespaces could solve? I have been with D for 14 years and haven't missed namespaces from C++ ever.

The reason I ask is, mentioning lack of features of other programming languages is not the right way to go. We have to understand what problem they were trying to solve with that feature and then see how D already tackels it.

In this case, it is namespacing and D solves it with the following feature and perhaps others that I can't think of:

- modules
- structs
- classes
- templates

I don't consider myself a maintainer of D but I don't agree that yet another feature for namespacing is needed. I feel that it would bring complications.

I don't think it is practical to bring all features of all languages into D or any other language.

> we've seen it used in the D
> library, so there's no excuse for why this shouldn't be added, in my
> opinion.

If I'm not mistaken you've counted five such instances. Were they really necessary? Could they be coded in a different way? What is the cost of missing namespaces? I think you are the first person raising this issue.

You must have a strong case for this feature; so, I recommend you write a DIP for it. It is likely that the mere act of doing that will expose hidden costs and usage problems.

Ali

On 2/5/23 14:40, ProtectAndHide wrote:

> On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear wrote:
>>
>> It's not a terrible workaround to be honest.
>> ....
>
> The 'terrible' part is this:
>
> - the compiler will allow you to declare a variable of type Algo
> - the compiler will allow you to declare an array with elements of type
> Algo
> - the compiler will allow you to use Algo as a type argument
> - the compiler will allow you to use Algo as a parameter
> - the compiler will allow you to use Algo as a return type

I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers?

Ali

On Sunday, 5 February 2023 at 23:50:35 UTC, Ali Çehreli wrote:
> On 2/5/23 02:57, thebluepandabear wrote:
>
> > When dealing with contexts, or for when you want a clear
> context in your
> > codebase, namespaces can be a life saver
>
> Can you give an example of a D problem that namespaces could solve? I have been with D for 14 years and haven't missed namespaces from C++ ever.
>
> The reason I ask is, mentioning lack of features of other programming languages is not the right way to go. We have to understand what problem they were trying to solve with that feature and then see how D already tackels it.
>
> In this case, it is namespacing and D solves it with the following feature and perhaps others that I can't think of:
>
> - modules
> - structs
> - classes
> - templates
>
> I don't consider myself a maintainer of D but I don't agree that yet another feature for namespacing is needed. I feel that it would bring complications.
>
> I don't think it is practical to bring all features of all languages into D or any other language.
>
> > we've seen it used in the D
> > library, so there's no excuse for why this shouldn't be
> added, in my
> > opinion.
>
> If I'm not mistaken you've counted five such instances. Were they really necessary? Could they be coded in a different way? What is the cost of missing namespaces? I think you are the first person raising this issue.
>
> You must have a strong case for this feature; so, I recommend you write a DIP for it. It is likely that the mere act of doing that will expose hidden costs and usage problems.
>
> Ali

I'm not going to create a DIP when I've hardly even touched the surface of the language, this is a beginners forum. I would need to wait 3-5 years until I'd feel comfortable doing so. Right now, it's not my place to be doing such things; this is just an observation from a beginner (aka me).

On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:
> On 2/5/23 14:40, ProtectAndHide wrote:
>
> > On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear
> wrote:
> >>
> >> It's not a terrible workaround to be honest.
> >> ....
> >
> > The 'terrible' part is this:
> >
> > - the compiler will allow you to declare a variable of type
> Algo
> > - the compiler will allow you to declare an array with
> elements of type
> > Algo
> > - the compiler will allow you to use Algo as a type argument
> > - the compiler will allow you to use Algo as a parameter
> > - the compiler will allow you to use Algo as a return type
>
> I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers?
>
> Ali

I don't see why you'd want to expose a static class/namespace as a variable, or any of such similar things. That would give no benefits to the programmer?

On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:
> On 2/5/23 14:40, ProtectAndHide wrote:
>
> > On Sunday, 5 February 2023 at 10:51:51 UTC, thebluepandabear
> wrote:
> >>
> >> It's not a terrible workaround to be honest.
> >> ....
> >
> > The 'terrible' part is this:
> >
> > - the compiler will allow you to declare a variable of type
> Algo
> > - the compiler will allow you to declare an array with
> elements of type
> > Algo
> > - the compiler will allow you to use Algo as a type argument
> > - the compiler will allow you to use Algo as a parameter
> > - the compiler will allow you to use Algo as a return type
>
> I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers?
>
> Ali

I do not agree, that a compiler that allows a programmer to misuse a type, should be seen as 'a feature'.

If that's the kind of 'power' D programmers want, then D is not for me.

>
> I do not agree, that a compiler that allows a programmer to misuse a type, should be seen as 'a feature'.
>
> If that's the kind of 'power' D programmers want, then D is not for me.

Eh, I don't think I would _quit_ D because of this issue, but it's definitely something that bothers me (more so the lack of an ecosystem) especially since I come from a .NET/JVM background. I'm pretty shocked this isn't a feature tbh.

On Sunday, 5 February 2023 at 23:53:35 UTC, Ali Çehreli wrote:
>
> I understand disabling the programmer to do certain things are beneficial e.g. to prevent bugs but those above can all be seen as features. What is so terrible about giving the programmer those powers?
>
> Ali

Interestingly, in Swift, you cannot (as far as I can tell) disable init() like you can in D. Thus you cannot prevent the programmer from creating an instance of a class.

And you can forget about 'C# like' static classes in Swift also.

That leaves the question of why 'any' programming language would allow you to instantiate a class that has only static members. What exactly are you going to do with that instance? (i.e. there are no 'instance' members, just 'type' members).

At least in D you CAN disable the initialiser with @disable.

But even after you've done that, the compiler still:
- allows you to declare a variable of that type
- allows you to declare an array with elements of that type
- allows you to use that type as a type argument
- allows you to use that type as a parameter
- allows you to use that type as a return type

So, getting back to your statement.. under what circumstance would a programmer want the 'power' to do any or all of this things, if the programmer has explicately disabled the initialiser, and the type has only static 'type' members?

On 2/5/23 18:15, ProtectAndHide wrote:

> I do not agree, that a compiler that allows a programmer to misuse a
> type

Types normally have objects. If a programmer found a way to use objects of a memberless type why stop them?

> should be seen as 'a feature'.

I am not saying I already see those uses as features. I am questioning why the compiler should ban certain features. Rather, why would a programmer decide that another programmer should not have objects of a certain type?

What is the actual insurmountable problem here? C#'s having 'static class' cannot be an answer because I can't imagine somebody even in C# wanted to have such a thing. For all I know, they wanted something else (namespacing in this case) and implemented it as 'static class'.

On the other hand, it is possible that C# brings different semantics that I don't know yet. What is that semantics? How does D already solve that?

> If that's the kind of 'power' D programmers want,

The trait here is orthogonality: Let's say A, B, C, etc. are features of a language. Some combination of those features work together for various reasons.

On the other hand, some combinations may not work well and people don't or can't use them for various reasons:

- The language may ban them because there may be dangerous ambiguities with that combination

- There may be technical impossibilities for that combination

- That combination can have no agreeable semantics (your earlier examples are in this category)

- People would never think about that combination (to me, at least some of your examples are in this category)

- People may decide not to use that combination in coding guidelines

- etc.

So, what I am understanding is that thebluepandabear and you are asking the compiler to ban certain combinations. For example, using a struct for namespacing (A) and being able to create objects (B) used together should not be allowed.

What other combinations can we come up with for such a list? As you said, certain uses of the 'static' keyword at module scope has no effect in D ('statis this' and 'shared static this' should be considered multi-word keywords and I think 'static const' has a meaning). Should the D spec enumerate all ineffective uses of 'static' (and others) and ban them? I don't agree.

In contrast, D delivers some features in an unprincipled way and the programmers use combinations of those features the way the see fit.

I really don't care if D had 'static class' to be used only as a namespace but I don't see how this issue is terrible. If the programmers ever need to use a struct (or a class) for namespacing then they wouldn't need objects of such types either. So, they wouldn't do that.

Ali

On 2/5/23 17:50, thebluepandabear wrote:

> I don't see why you'd want

I am not saying it would be wanted or needed.

> to expose a static class/namespace as a
> variable, or any of such similar things. That would give no benefits to
> the programmer?

Perhaps. As I responded to ProtectAndHide, if there is a benefit then it is useful by definition; if there is no benefit then it wouldn't be used anyway.

Ali