October 20, 2021
On Wed, Oct 20, 2021 at 11:41:32AM +0000, Adam D Ruppe via Digitalmars-d wrote: [...]
> Well, one idea I heard last week that I don't loathe and despise is that classes are always *explicit* references.
> 
> class Object {}
> 
> void foo(Object* o){}
> 
> That'd be the new syntax for what we have today. But:
> 
> void foo(Object o) {} // error: cannot declare variable of class value type; the rule is still they're always references
> 
> 
> One of the benefits of this is there's now a place for rebindable:
> 
> 
> void foo(const(Object)* o) {} // const object, but you can rebind the
> reference
[...]

Now *that* is a cool idea that might actually be worth doing. This would also make it easier to refactor programs switching between class/struct: switching from class to struct will retain reference semantics without any trouble, and switching from struct to class will automatically catch all the places that need attention because of potential change in semantics.


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
October 20, 2021
On Wednesday, 20 October 2021 at 11:41:32 UTC, Adam D Ruppe wrote:

> I don't really think it is worth the hassle but it is interesting in that it solves some old syntax worries.

It totally worth it, it part of the reason why i avoid classes, even thought i could malloc them.. i just don't want to introduce the concept of ``MyObject`` pointers without the star ``*``

It will introduce too much bugs and constantly having to check signature of parameters IS A PAIN that needs to go away, the sooner, the better
October 20, 2021
On Wednesday, 20 October 2021 at 11:41:32 UTC, Adam D Ruppe wrote:
>
> Well, one idea I heard last week that I don't loathe and despise is that classes are always *explicit* references.
>
> class Object {}
>
> void foo(Object* o){}
>
> That'd be the new syntax for what we have today. But:
>
> void foo(Object o) {} // error: cannot declare variable of class value type; the rule is still they're always references
>
>
> One of the benefits of this is there's now a place for rebindable:
>
>
> void foo(const(Object)* o) {} // const object, but you can rebind the reference
>
>
>
> That const ref thing has come up for about as long as D has had const.
>
>
> I don't really think it is worth the hassle but it is interesting in that it solves some old syntax worries.

Just a small question, if you want a raw pointer to your object how would that look like. Since Object* is a reference (with things going on behind the scene), what is the raw pointer?
October 20, 2021

On Wednesday, 20 October 2021 at 09:47:54 UTC, SealabJaster wrote:

>

Just for giggles, without pesky things like breaking changes; rational thinking, logical reasoning behind the changes, etc.

What interesting changes would you make to the language, and what could they possibly look like?

Optional access operator. I tend to write more and more conditional expression with null as the third operand.

For example I count 93 occurences of the pattern in styx.
Not convinced that this is a very common construct ?
Let's take a look at dmd: 490 occurences.

Example picked from dmd:

StringExp se = ex ? ex.ctfeInterpret().toStringExp() `: null`;"

becomes

StringExp se = ex?.ctfeInterpret().toStringExp();

Please abstraint you to reply to me with remarks like "this can be done using metaprog" ... I know because I did it too a few years ago (using opDispatch).

This should be built in the language because

  1. the template solution is necessarily slow to compile
  2. it is better for tooling
October 20, 2021
On Wed, Oct 20, 2021 at 03:43:56PM +0000, IGotD- via Digitalmars-d wrote: [...]
> Just a small question, if you want a raw pointer to your object how would that look like. Since Object* is a reference (with things going on behind the scene), what is the raw pointer?

Object* *is* the pointer.  There's nothing going on behind the scenes.

Or, in present notation, cast(void*)Object gives you the pointer.


T

-- 
Study gravitation, it's a field with a lot of potential.
October 20, 2021
On Wednesday, 20 October 2021 at 15:53:53 UTC, H. S. Teoh wrote:
> Object* *is* the pointer.  There's nothing going on behind the scenes.

well tho does obj++; move the pointer or call the operator on the class?

I don't think this syntax is ideal (I kinda prefer the old `Object ref` proposal), but just it is something interesting to think about.
October 20, 2021

On 10/20/21 11:58 AM, Adam D Ruppe wrote:

>

On Wednesday, 20 October 2021 at 15:53:53 UTC, H. S. Teoh wrote:

>

Object* is the pointer.  There's nothing going on behind the scenes.

well tho does obj++; move the pointer or call the operator on the class?

Yeah, this proposal falls apart there. I don't think it's viable.

If obj++ doesn't mean go to the next Object, then you are trading one WTF for another.

>

I don't think this syntax is ideal (I kinda prefer the old Object ref proposal), but just it is something interesting to think about.

I actually wrote an unpublished blog article (from 2013) arguing for something to fix this (it fixes a lot of other things too). But I received such negative feedback, I abandoned it.

-Steve

October 20, 2021

On Wednesday, 20 October 2021 at 10:26:52 UTC, IGotD- wrote:

>

On Wednesday, 20 October 2021 at 10:23:27 UTC, SealabJaster wrote:

>

So something like int^ to denote a GC pointer, and int* for a raw pointer?

Something like that, which is exactly the syntax of "Managed C++".

What is the benefit of different pointer types?

If you have a function that takes a pointer but doesn't make any allocations or anything, then you would need to have two versions of it to work with each type. This introduces a similar issue as what led to inout. It might make some kind of generics with type erasure that can handle all of these cases more useful.

October 20, 2021
On Wednesday, 20 October 2021 at 11:41:32 UTC, Adam D Ruppe wrote:
>
> I don't really think it is worth the hassle but it is interesting in that it solves some old syntax worries.

One of the problem C++ has with objects-with-inheritance-as-value-type is "object slicing".

It is ugly in theory: https://stackoverflow.com/a/14461532

I guess it's one of the reason D doesn't have that, so a discussion about Object* needs to address that issue.
October 20, 2021
On Wednesday, 20 October 2021 at 17:28:30 UTC, Guillaume Piolat wrote:
> One of the problem C++ has with objects-with-inheritance-as-value-type is "object slicing".

That's why:

void foo(Object o) {} // error: cannot declare variable of class value type; the rule is still they're always references

It still requires you to always use it by reference, you just have to write it out differently.