On 2014-01-18 12:21, Daniel Murphy wrote:

> Exactly.  It _could_ be done in the frontend, but it hasn't.

I see, thanks.

-- 
/Jacob Carlborg

On 2014-01-17 17:52:18 +0000, "Yota" <yotaxp@thatGoogleMailThing.com> said:

> On Friday, 17 January 2014 at 15:05:10 UTC, Michel Fortin wrote:
>> Couldn't we just add a class declaration attribute that'd say that by default this type is not-null?
> 
> I have been hoping D would become not-null-by-default since I discovered the language.  Looking at what it has done with other type classes, (shared, immutable, etc) it always seemed like something that would be right up its alley.  However in my dream world, it would simply apply to all reference types by default.

Well, nothing prevents that from happening if @notnull is adopted. As proposed, @notnull is designed to keep the language backward compatible: it's opt-in and you don't even have to opt-in all at once. Potential problems the early implementation might have can only burn those who give it a try.

One can hope the feature will become so loved that it'll become standard pointer behaviour one day, but that can't happen as long as the feature is theoretical. In the eventuality we decide one day to push not-null behaviour to the rest of the language, @notnull will just become an attribute with no effect.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 01/18/2014 12:37 AM, Walter Bright wrote:
>
> Come on. Every type in D has a default initializer.

This is not true any longer. There is @disable this().

On 1/17/2014 7:05 AM, Michel Fortin wrote:
> Some more thoughts.

The postfix ? has parsing issues with ?: expressions.

Aside from that, non-null is only one case of a universe of types that are subsets of other types. I'd prefer a more general solution.

On Saturday, 18 January 2014 at 21:05:02 UTC, Walter Bright wrote:
> On 1/17/2014 7:05 AM, Michel Fortin wrote:
>> Some more thoughts.
>
> The postfix ? has parsing issues with ?: expressions.
>
> Aside from that, non-null is only one case of a universe of types that are subsets of other types. I'd prefer a more general solution.

Whats about a new storage class/modifier like @safe_ref/@disable_null/@disallow_null?

----
class A { }

void test(@safe_ref A) {

}

A a;
test(a); // error
----

and maybe also:

----
@safe_ref A a; // error
----

On 1/17/2014 7:38 PM, Walter Bright wrote:
> On 1/17/2014 7:23 PM, Michel Fortin wrote:
>> I guess so. But you're still unconvinced it's worth it to eliminate null
>> dereferences?
>
> I think it's a more nuanced problem than that.

I should clarify that. I oppose solutions that replace the null seg fault with another bug that is harder to detect. (I know this is not what you have proposed.)

bearophile proposes the following syntax:
> T? means T nullable
> T@ = means not nullable.

Here: http://d.puremagic.com/issues/show_bug.cgi?id=4571
And here: http://forum.dlang.org/thread/mailman.372.1364547485.4724.digitalmars-d@puremagic.com?page=6#post-jlqdndoqeuhixxcmcbar:40forum.dlang.org

Namespace:

> bearophile proposes the following syntax:

In this case the semantics matters much more than the syntax :-)

Bye,
bearophile

On 2014-01-18 21:05:01 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 1/17/2014 7:05 AM, Michel Fortin wrote:
>> Some more thoughts.
> 
> The postfix ? has parsing issues with ?: expressions.

I thought that because the left hand side was a type it could be disambiguated. Somewhat like '*' is disambiguated between pointer declaration and multiplication depending on whether the left hand side is a type.

	int * a; // pointer declaration
	a * b; // multiplication

But I might be wrong, especially since ?: is a trinary operator while * is always binary.


> Aside from that, non-null is only one case of a universe of types that are subsets of other types. I'd prefer a more general solution.

Hum, kind of thing do we want to support in a general solution?

The closest thing I can think of is range constrains. Here's an example (invented syntax):

	void test(int!0..10 a) // param a is in 0..10 range
	{
		int b = a; // fine
		int!0..5 c = a; // error, incompatible ranges
		int!0..5 d = a/2; // fine, can't escape range

		if (a < 5)
			d = a; // fine, 'a' is int$0..5 on this branch
	}

Obviously compiler code for range constrains and non-null pointers would be shared to some extent, as the rules are pretty similar.

But what other cases should be covered by a more general solution? Do we want to add a way for users to declare their own custom type modifiers that can do things? That depends on control flow?


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 1/18/2014 1:38 PM, Michel Fortin wrote:
> The closest thing I can think of is range constrains. Here's an example
> (invented syntax):


I don't think a new syntax is required. We already have the template syntax:

   RangedInt!(0,10)

should do it.