On 2012-11-05 22:01, Namespace wrote:

> Works in the current Remus version with: [code]a ?= new Foo();[/code] ;)

Cool.

-- 
/Jacob Carlborg

On Monday, 5 November 2012 at 17:54:32 UTC, Namespace wrote:
> I am considering to rewrite Remus from the ground up.
> Because I hope that Remus earn next time more interest, I would like to vote or discuss the features.
> As there would be:
>   - Not null references. Example: Foo& f / int& i. Maybe only for Objects?
>   - not null safe invocation. Example: some_obj?.do_something();
>   - Elvis operator. Example: Foo result = foo ?: new Foo();
>   - Stack instances with own keyword? For example, with 'local' as it is now.
>   - Package import? Example: import package std: stdio, array, regex;
>   - Namespaces?
>
> What is preferred by this list / what not? What should be included in any case in Remus / what not?

I'm learning the D language right now, and I can not say that I've missed any of these things. They may offer some 'syntactic sugar', but the D is very expressive anyway. Ex: for safe invocation I would use an assert/enforce anyway if there is a chance the object is null. The 'import package' whould be usefull though...

> I'm learning the D language right now, and I can not say that I've missed any of these things. They may offer some 'syntactic sugar', but the D is very expressive anyway. Ex: for safe invocation I would use an assert/enforce anyway if there is a chance the object is null. The 'import package' whould be usefull though...

Which language(s) did you use before? Java? ;)

On Tuesday, 6 November 2012 at 16:39:24 UTC, Namespace wrote:
>> I'm learning the D language right now, and I can not say that I've missed any of these things. They may offer some 'syntactic sugar', but the D is very expressive anyway. Ex: for safe invocation I would use an assert/enforce anyway if there is a chance the object is null. The 'import package' whould be usefull though...
>
> Which language(s) did you use before? Java? ;)

I'm on the C++ wagon, thus the plain and simple (though expressive) syntax of D is what keeps me here :-)
It is just my opinion, because you asked for feedback :-) Hack forward as you like it...

On Tuesday, 6 November 2012 at 20:03:21 UTC, Tavi Cacina wrote:
> On Tuesday, 6 November 2012 at 16:39:24 UTC, Namespace wrote:
>>> I'm learning the D language right now, and I can not say that I've missed any of these things. They may offer some 'syntactic sugar', but the D is very expressive anyway. Ex: for safe invocation I would use an assert/enforce anyway if there is a chance the object is null. The 'import package' whould be usefull though...
>>
>> Which language(s) did you use before? Java? ;)
>
> I'm on the C++ wagon, thus the plain and simple (though expressive) syntax of D is what keeps me here :-)
> It is just my opinion, because you asked for feedback :-) Hack forward as you like it...

No offense. :)
But if you came from C++: didn't you miss (not-null) references?

On Tuesday, 6 November 2012 at 22:00:47 UTC, Namespace wrote:
> No offense. :)
> But if you came from C++: didn't you miss (not-null) references?

You could perform trickery and create null references in C++ and the compiler would not catch it, but you'd have to intentionally mess around and do dangerous things.

I do agree that not null references is an item D could really use. Of course you'll need to also allow nullable references too because that is also extremely useful, so really what you want is ability to pick and choose which references are guaranteed to never be null and which can be null. By default it should be not nullable. There was a thread in here on this topic not long ago, but Im not so sure we'll get to see it in D any time soon.

--rt

On Mon, 05 Nov 2012 18:54:31 +0100, Namespace <rswhite4@googlemail.com> wrote:

> I am considering to rewrite Remus from the ground up.
> Because I hope that Remus earn next time more interest, I would like to vote or discuss the features.

Writing a D parser from the ground up, even if it's basic, seems to be an awful waste of time.

Check out my D compiler to see if it could serve any of your purposes:

https://github.com/azizk/dil

On Wednesday, 7 November 2012 at 08:26:25 UTC, Aziz K. wrote:
> On Mon, 05 Nov 2012 18:54:31 +0100, Namespace <rswhite4@googlemail.com> wrote:
>
>> I am considering to rewrite Remus from the ground up.
>> Because I hope that Remus earn next time more interest, I would like to vote or discuss the features.
>
> Writing a D parser from the ground up, even if it's basic, seems to be an awful waste of time.
>
> Check out my D compiler to see if it could serve any of your purposes:
>
> https://github.com/azizk/dil

Thanks a lot, but my Lexer/Parser isn't that smart and I think I need nothing wiser. But thanks, maybe I find some nice features which I can implement by my own. :)

Rob T:
Absolutely right. Hence the brackets around "non-null" is. ;)
First of all, I plan to implement real not-null references. I hope that I receive some feedback then.

Another interesting possible feature for Remus: as the usage of immutable structs becomes more common in D code, it becomes more useful a syntax to create an updated struct. Similar syntax is present in F# and other functional languages.

struct Foo { int first, second, third; }
immutable f1 = Foo(10, 20, 30);

Current syntax:
immutable f2a = Foo(f1.first, 200, f1.third);

A possible syntax:
immutable f2b = Foo(f1 with second = 200);

Bye,
bearophile

On Thursday, 8 November 2012 at 03:21:03 UTC, bearophile wrote:
> Another interesting possible feature for Remus: as the usage of immutable structs becomes more common in D code, it becomes more useful a syntax to create an updated struct. Similar syntax is present in F# and other functional languages.
>
> struct Foo { int first, second, third; }
> immutable f1 = Foo(10, 20, 30);
>
> Current syntax:
> immutable f2a = Foo(f1.first, 200, f1.third);
>
> A possible syntax:
> immutable f2b = Foo(f1 with second = 200);
>
> Bye,
> bearophile

That sounds like named parameters, which I don't like very much. :/