A collection of DIPs

[Enamex via Digitalmars-d]

On Monday, 7 September 2015 at 14:44:05 UTC, nx wrote:
> https://github.com/NightmareX1337/DX
>
> Don't kill me, I'm just trying to help...
>
> You can report issues and create pull requests :)
>
>> Destroy!

- Your point against undisciplined UFCS: Completely agree.

I'm writing a 'DIP' that I'm probably never gonna submit to add 
"extension interfaces" (my syntax ATM is leaning towards "alias 
class/interface") that add callable-with-method-syntax free 
functions in a way that they're treated as native parts of the 
supporting type (one case: when passing the type name into a 
foreign template they're picked up as if they were methods 
instead of being out-of-scope).

In a (very big) way, they're stolen whole-sale and are being 
adopted to fit from Rust's traits.

- Null-coalescing operator: No. Pattern matching and a 
`std.typecons.Option(T)` would do better IMHO and are more 
general.

- I've stayed away from UDAs but your points make me finally want 
to stay away a bit more. (except for a small side project but, 
well, necessities)

- Managed~unManaged pointers: needlessly complicated. Just 
provide a non-GC 'new'. What wouldn't that solve as well as your 
`type*` vs `type^` pointers? (btw, `^` wouldn't conflict with the 
xor-operator as I understand it. `!` is already used both as a 
unary prefix and binary infix operator).

- Not sure about `alias this`/`opCast`. I just use `opDispatch` 
whenever I need something more complicated than alias this (not 
much at all).

- I VERY strongly believe in the inherent superiority of 
kebab-case compared to CamelCase and snake_case. KEBAB-CASE FOR 
PRESIDENT!

- I hated D's module system at first. I still hate that I have to 
create separate files just to have a small internal 
namespace-separation. But I like being able to just go find 
something in a file in a project based on its compile-time path 
(granted, good design should enforce this but...). I dunno; on a 
fence about it.

- `__traits(callerName) & __traits(callerChain) & 
__traits(callerPath)`: I want a `__traits(instanceContext, 
symbol)` that returns an alias allowing me to access all 
compile-time info on surrounding symbols to the passed one (which 
are local to the /instance/ so include imported names and local 
types and such). That would solve SO MANY THINGS with template 
adventures. Not sure on what it'd make worse, though.

- Partial lock for arrays: Sounds complicated for D's current 
analysis abilities. But sounds cool.

- pragma(inline): ABSOLUTELY. The idea that `pragma(inline)` 
verbatim tells the compiler precisely nothing hurts my OCD so 
much.

- Old attributes got a space in the keyword list. There were 
proposals to shift them all to `@` syntax but it stalled early on.

- Runtime reflection: Hmmm... Runtime UDA's sound suspiciously 
like a type-state system. Complicated, interesting.

- Templates are obvious enough as they are IMHO.

- Friend classes: Um, maybe make a separate MyTypeImpl 
struct/class that takes a MyType instance and initializes itself 
with a pointer and through it you can access all the private 
stuff you want? (MyTypeImpl would be in the same module as 
MyType, of course.)

Good stuff ;)