1.
Why are these two method header identitcal?

const Foo some_function() {

and

Foo some_function() const {

?

IMO that isn't consistent. IMO only the last is valid.
With this example, it is somewhat understandable.

// C++
class Bar {
    const Foo getFooObj() const { ... }
    const Foo& getFooObjRef const { ... }
};

// D
class Bar {
    const(Foo) getFooObj() const { ... }
    ref Foo getObjRef() { ... }
}

const(Foo) but ref Foo. This is inconsistency, if you ask me.
So why is between C++ and D such a huge difference?
Why isn't it simply const Foo instead of const(Foo)?

2.
What's about a shorthand for debug assertions?
E.g. to avoid not-null references (yes, if you're a windows user, you hate them):

Example:

[code]
void some_function(Foo !f) {
[/code]

will automatically converted by the compiler into:

[code]
void some_function(Foo f, string filename = __FILE__, uint line = __LINE__) in {
    assert(f !is null, format("Null Object @ file %s on line %d.", filename, line));
} body {
[/code]

That would be avoid many many efforts by writing safe code. And it avoids Java code stil with explizit pre- and postconditions which blows up code.

On Friday, 27 July 2012 at 10:29:15 UTC, Namespace wrote:
> 1.
> Why are these two method header identitcal?
>
> const Foo some_function() {
>
> and
>
> Foo some_function() const {
>
> ?
>
> IMO that isn't consistent. IMO only the last is valid.
> With this example, it is somewhat understandable.

Some would argue only the *first* should be valid:

----
@safe const @property nothrow
Foo some_function();
----

Basically, yeah, you have the option of putting qualifiers before or after.

On 2012-07-27 12:29, Namespace wrote:
> 1.
> Why are these two method header identitcal?
>
> const Foo some_function() {
>
> and
>
> Foo some_function() const {
>
> ?

The reason "const Foo some_function" is allowed is because in D this syntax is possible:

class Foo
{
    const:

    Foo some_function () {}
}

> IMO that isn't consistent. IMO only the last is valid.
> With this example, it is somewhat understandable.
>
> // C++
> class Bar {
>      const Foo getFooObj() const { ... }
>      const Foo& getFooObjRef const { ... }
> };
>
> // D
> class Bar {
>      const(Foo) getFooObj() const { ... }
>      ref Foo getObjRef() { ... }
> }
>
> const(Foo) but ref Foo. This is inconsistency, if you ask me.
> So why is between C++ and D such a huge difference?
> Why isn't it simply const Foo instead of const(Foo)?

I think the reason is the same as above. If the return value is const you need to use parentheses. I think that the syntax would conflict with the const-method syntax otherwise.

The reason for why const is allowed after the paramter list is because it can be a bit confusing to have two const next to each other.

class Foo
{
    const const (Foo) foo () {}
}

-- 
/Jacob Carlborg

On 2012-07-27 13:14, Jacob Carlborg wrote:
> On 2012-07-27 12:29, Namespace wrote:

>> const(Foo) but ref Foo. This is inconsistency, if you ask me.
>> So why is between C++ and D such a huge difference?
>> Why isn't it simply const Foo instead of const(Foo)?
>
> I think the reason is the same as above. If the return value is const
> you need to use parentheses. I think that the syntax would conflict with
> the const-method syntax otherwise.
>
> The reason for why const is allowed after the paramter list is because
> it can be a bit confusing to have two const next to each other.
>
> class Foo
> {
>      const const (Foo) foo () {}
> }
>

Forgot to say, the reason for why the ref(Foo) syntax isn't used is because there can be no conflict since methods cannot be declared as const.

-- 
/Jacob Carlborg

> The reason "const Foo some_function" is allowed is because in D this syntax is possible:
>
> class Foo
> {
>     const:
>
>     Foo some_function () {}
> }

Good point. I had completely forgotten, that that is possible.
But it seems that no one would have interest in my second proposal. :)

Namespace:

> Good point. I had completely forgotten, that that is possible.
> But it seems that no one would have interest in my second proposal. :)

Similar things were discussed a lot. And some people think that similar nonnull annotations are a good idea.

Bye,
bearophile

On Friday, 27 July 2012 at 11:50:46 UTC, bearophile wrote:
> Namespace:
>
>> Good point. I had completely forgotten, that that is possible.
>> But it seems that no one would have interest in my second proposal. :)
>
> Similar things were discussed a lot. And some people think that similar nonnull annotations are a good idea.
>
> Bye,
> bearophile

Then: What is the problem to introduce such shorthand?
To solve the problem with a struct is IMO a really _bad_ idea.
Because then you have to pack the object into the struct (or you have to create the object with a function that returns this struct, equally as "scoped" does it currently) and _then_ you can pass it to the function/method.
Still the same effort as if you solve it with preconditions.
Completely unnecessary work, and such shorthand can avoid this.

Namespace:

> Then: What is the problem to introduce such shorthand?

I don't know.
I have a partial enhancement on the topic:
http://d.puremagic.com/issues/show_bug.cgi?id=4571

Bye,
bearophile

On Fri, 27 Jul 2012 14:44:35 +0200, bearophile <bearophileHUGS@lycos.com> wrote:

> Namespace:
>
>> Then: What is the problem to introduce such shorthand?
>
> I don't know.
> I have a partial enhancement on the topic:
> http://d.puremagic.com/issues/show_bug.cgi?id=4571
>
> Bye,
> bearophile

I believe at least part of the explanation is that Walter wants NotNull to
implemented in a library. That's part of the reason for introducing
@disable this().

Now, one could certainly argue that int? be translated by the compiler into
NotNull!int, and the implementation lie in druntime.

-- 
Simen

bearophile:
Yes i know, but i see there no answers.

Simen Kjaeraas:
That's exactly what i mean. Foo? or Foo! would be converted into NotNull!Foo.

I wrote a quick and dirty solution:
http://dpaste.dzfl.pl/400079cb

Which converts this Code:

[code]
import std.stdio;

class Foo {
public:
	void echo() const {
		writeln("My Name is Foo.");
	}
}

void foo(Foo! f) {
	f.echo();
}

void bar(Foo! f) {
	f.echo();
}

void main() {
	Foo f = new Foo();
	Foo f2;
	
	foo(f);
	bar(f2);

	foo(new Foo());
	bar(null);
}
[/code]

into: http://dpaste.dzfl.pl/d9375eeb

It is not perfect, but a first step. It would be desirable if the dmd compiler could do something on its own.

What are the chances that something like this happens?