Issue 1:
I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[ x ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

AbstractControl.get allows a flexible path parameter, for specifying the required descendent AbstractControl to return.

Expected behavior

AbstractControl.getChild<T>(key: keyof T) would allow additional type safety, in the case where the required AbstractControl is a direct child of the instance AbstractControl-derived parent.

Here, T refers to the type of the data model, i.e. the type of AbstractControl.value.

In fact, this method is probably only suitable for FormGroup.

Further, the following signature:

AbstractControl.getChild<T, C extends AbstractControl>(key: keyof T): C | null

would allow the caller to indicate the expected sub-type of AbstractControl to be returned.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Reduce the risk of typos in the string value passed to the proposed getChild method.

Please tell us about your environment:

Angular version: 4.1.3

Browser: [ all ]

Language: [ TypeScript 2.X ]

Node (for AoT issues): node --version =

Issue 2:
As far as I can tell there is no good way to make a decorator conditionally applied. My experience is with Angular 2 in Dart, for an internal app (zny@). This is a feature request for some template syntax or something similar (maybe an automatically generated input for all directives like applyDirectiveName?) to allow for a decorator to be conditionally applied to an element.

There are several possible workarounds in lieu of this feature, all of which are significantly bad:

Duplicate the code in the template, and have one version with the decorator, one without. This is bad because it requires duplication, and if there's content inside the decorated element it could be a lot of duplication.

<div *ngIf="condition" decorator>lots-of-content-goes-here</div>

<div *ngIf="!condition">lots-of-content-goes-here</div>

Add an input to the decorator that turns it on or off. This is bad because it requires an extraneous input just to say "don't do anything at all" and can be confused with similar inputs (e.g. a button decorator that has a disabled input). Also bad because you may be using a decorator from a library or some such where you cannot easily add this yourself.

<div decorator decorator-input="condition">content</div>

Create a base class for the decorator and have it share most stuff, where one impl takes a conditional input and the other doesn't, this is impossible to do well because you cannot share the properties passed to the decorator: #6575

Create a component that wraps the content twice, once with decorator and once without, and then ngIf between the two based on the conditional. This is impossible because you cannot project the same content twice into an ng-content (see e.g. this comment for some discussion, I didn't open an issue because this appears to be by design: #4631 (comment) )

`@Component(selector: 'conditional-decorator-wrapper',

directives: const [ExampleDecorator],

template: '<div *ngIf="condition" exampleDecorator>

')`
`class ConditionalDecoratorWrapperComponent {}`