►
From YouTube: .NET Foundation Project Spotlight - Roslyn
Description
.NET Foundation Marketing Committee member Isaac Levin spoke to Jared Parsons, one of the maintainers of Roslyn. For more detail, be sure to check out the Project Spotlight page
https://dotnetfoundation.org/projects/spotlight?project=Roslyn
A
Welcome
everybody
to
the
newest
iteration
of
this
month's
project,
spotlight
we're
continuing
with
the.net
theme
of
c
sharp
and
I'm
super
excited,
because
we
have
somebody
who
knows
a
little
bit
about
c
sharp
and
the
runtime
and
compiler.
So
I'm
super
excited
to
introduce
jared
parsons
jared.
Do
you
want
to
say
hello
and
introduce
yourself.
B
Hey
everyone,
so
I'm
jared
parsons,
I
am
the
developer,
lead
on
the
c-sharp
compiler
team,
I'm
also
a
member
of
the
c
sharp
language
design
team.
I've.
Actually,
overall,
I've
been
at
microsoft
for
about
17
years
now,
and
a
little
over
15
of
those
years
have
been
working
in
kind
of
like
dot,
net,
tooling
and
languages
in
one
way
or
the
other.
So
something.
A
About
yeah
and
I'm
super
excited
to
to
talk
with
you,
because
for
one
as
a
developer,
at
least
I
call
myself
a
developer.
I
know
I'm
a
developer
anymore
compilers
when
I
took
them
in
school,
it
was
even
after
completing
the
course
it
was
still
like
black
box
right,
and
I
think
I
have
a
lot
of
interesting
people
that
they
love
working
on
compilers
and
I
love
working
on
kind
of
how
the
the
sausage
gets
made.
B
Sure,
well,
at
first
there's
one
comment
you
made
there
about
like
taking
compilers
in
college,
and
it
reminds
me
that
when
I
took
compilots
in
college,
I
decided
that
I
hated
them
sure
and
that
to
the
point,
when
I
joined
microsoft,
when
they,
basically
when
you
back
in
those
days,
they
have
a
checkbox
they're
like
what
are
your
interests.
I
checked
every
box
except
for
web
development
and
compilers,
because
I
was
like
no
way
I'm
going
near
those
again
and
it
turned
out.
B
I
ended
up
on
a
different
team,
but
eventually
got
transferred
into
the
compiler
team,
because
there
were
two
things:
it's
like
one.
I
understood
what
compilers
were
and
I
liked
the
person
I
had
previously
worked
for
the
person
who's
in
charge
of
them
and
it
turned
out
that
production,
compilers
and
like
actual
real
languages
are
a
lot
different
than
what
you
learned
kind
of
in
college.
So
it
was
a
lot
more
fun
to
work
on
those
than
what
we're
doing
in
college.
B
But
in
terms
of
my
role
kind
of
like,
as
I
said,
I'm
the
deadline
on
the
c-sharp
team,
and
so
those
things
with
those
involve
is
basically
I
do
the
way
the
c-sharp
language
works
is
it's
actually
kind
of
two
parts.
There
is
kind
of
the
language
design
team,
which
is
a
team
of
people
who
kind
of
go
through
and
kind
of
they
kind
of
set
the
direction
of
the
language
like
here
like
we
want
to
do
this
set
of
features.
B
B
So
I
am
mostly
my
primary
job
is
in
charge
of
that
ladder
bit
like
how
do
we
collect
the
series
of
proposals
that
the
language
design
team
has
done
and
how
do
we
kind
of
turn
them
into
a
product
that
can
customers
can
have
how
to
get
into
visual
studio?
How
to
get
to
the
net
sdk?
I
also
do
work
on
the
language
design
team,
as
well
as
about
half
the
compiler
team
as
a
part
of
that,
and
so
we
do
spend
a
lot
of.
We
are
also
very
involved
in
how
the
language
evolves.
There.
A
Yeah,
that's
there's
a
lot
there
and
I
guess,
as
you
know,
with
the
moniker,
definitely
the
the
list
of
things
that
you
will
quote
unquote
are
owner
responsible
for
when
you
lift
it
all
out,
you
probably
need
a
breath.
I
think
one
of
the
things
I'm
very
curious
about
is
obviously,
since
most
of
the
work
that
you're
doing
is
out
in
the
open.
It's
it's
on
github.
How
does
the
community
so
obviously
with
the
runtime
and
compiler
all
things?
A
These
are
things
that
are
directly
tied
to
like
core
products
that
an
organization
owns
right
that
microsoft
owns,
but
you
do
all
the
work
out
in
the
open.
So
how
does
you
know
the
balance
of
community
contribution
versus
you
know,
like
you
said,
making
sure
that
the
product
is
still
resilient,
and
you
know
I
guess
at
the
end
of
the
day,
how
do
you
balance
those
two
things.
B
It
can
be
challenging
at
times,
so
we
so
one
thing
that
when
we
so
we've
been
open
source
about
like
five
years
now,
five
or
six
years
now-
and
I
remember
like
one
of
the
things
that,
when
we
kind
of
were
making
that
transition
from
a
closed
source
company
to
an
open
source,
one
is
I
had
to
kind
of
like
we
had
to
do
a
lot
of
management,
education
for
our
management
structure
and,
for
instance,
like
I
had
to
talk
to
my
management
team
about
they're
like
oh
they're.
B
All
these
like
prs
and
github
like
this
is
great.
This
is
free
features,
free
work
and
it's
all
good,
I'm
like!
No!
No,
no,
it's
not
free
like
it's
like
pr
from
the
community
is
no
different
than
a
pr
from
us.
It's
something
that
we
have
to
spend
time.
It's
a
it's
a.
We
have
to
allocate
resources
to
review
it
and
incorporate
it
into
our
product,
and
that's
also
why
I
started
like
emphasizing
more
reviews
like
how
much
time
were
various
steps.
B
Spending
on
like
getting
community
prs
merged
in,
as
opposed
to
like
getting
internal
work
merged
in,
and
it's
overall
like
it's
a
huge
network
to
get
like
work
from
the
community,
but
it
is
just
something
that
we
have
to
spend
time
kind
of
like
allocating
for
and
in
terms
of
how
we
balance
it.
It
can
be
a
bit
challenging
because
one
of
the
biggest
challenges
is
the
community
is
kind
of
unpredictable
sure.
Like
I,
I
have
a
series
of
devs
like
we
have
one
on
one.
So
we
have
a
plan.
A
B
This,
like
you
know
this
feature
like
spec
over
there,
and
I
thought
about
it
for
a
while
and
here's
like
an
implementation,
and
so
it
can
kind
of
be
like
this
unscheduled,
unplanned
work
in
terms
of
how
you
balance
it
you
it
can
be
challenging
like
one
you
have
to
be
pretty
flexible.
You
have
to
be
able
to
kind
of
have
an
expectation
of
like
okay,
we'll
probably
get
based
on
history,
we'll
probably
get
a
certain
number
of
prs
and
like
we
can
probably
take
a
kind
of
a
baseline
level
of
noise.
B
B
Should
we
maybe
push
this
work
that
we
were
gonna
do
like
push
it
back
two
weeks
so
that
we
have
enough
time
to
review
this
community
contribution,
or
should
we
tell
the
community
member,
like
hey,
we're
really
in
the
thick
of
things
right
here,
we're
kind
of
at
capacity
right
now
we
will
get
back
to
you.
We
really
enjoy
this,
but
we
just
don't
have
time
right
now
to
review
it.
B
We
will
get
back
to
you
one
month,
two
months
but
like
please
don't
go
away,
and
so
it
requires
both
kind
of
flexibility
on
my
part
and
flexibility
kind
of
on
the
community
to
understand
that
their
work
can
sometimes
be
surprising
to
us
in
general,
though,
what's
really
good
is
we
do
have
enough
regular
contributors
now
that
they
have
found
like
good
channels
of
talking
with
us,
on
either
like
discord
or
github
and
they're
getting
much
better
about
killing
kind
of
telling
us
their
plans
like
hey,
I'm
gonna
take
a
crack
at
this,
like
we
have
one
community
member
alrz
who
was
like
hey.
B
I
saw
that
you
all
have
a
kind
of
list
patterns
thing
you
have
it
almost
done
like.
Can
I
try
that
and
he
was
like
I'm
thinking
about
trying
it
kind
of
in
this
time
span
and
it's
like.
Oh,
this
is
great.
I
can
plan
about
these
things.
It's
supposed
to
just
be
like
a
oh
crap,
there's
a
great
pr
like
do.
We
have
enough
time
to
ship
that
so
yeah
and
the
planning
is
actually
really
hard,
sometimes
because
one
thing
that
I
think
people
don't
realize
with
language
features
is
they
tend
to?
B
I
think,
a
lot
of
times
community
kind
of
tends
to
think
about
language
feature
as
like
at
the
compiler
level
like
I
have
a
syntax,
I
type
in
in
an
invent
code,
and
while
that's
partially
true,
c,
sharp,
like
compilers,
are
really
defined.
Languages
are
really
defined
by
the
ecosystem
of
the
experiences,
and
so
it's
not
just.
I
can
translate
text
to
code
like
you.
Have
that
that's
more
of
a
toy
like
it's.
Do
I
get
intelligence
in
visual
studio?
Do
I
get
highlighting
for
like?
What's
the
debugging
experience?
Do
we
have
refactorings?
B
It's
like
this
whole
experience,
and
so
what
can
be
really
challenging
is
sometimes
the
community
ends
up
picking
up
features
where
we
take
a
look
at
that,
and
I'm
like
that,
has
a
huge
impact
on
how
visual
studio
works
and
how
we
kind
of
like
do
intellisense
and
formatting,
and
so
then
we
have
to
go
and
like
bring
other
leads
in
and
be
like.
Hey
we're
gonna
do
this
feature
now
it's
really
gonna
cost
you
because
you
have
to
like
implement,
like
you
know
some
better
parsing
on
top
of
it.
So
that's
it.
A
Yeah,
no,
I
mean
that
it
sounds
like
a
lot
like
it's
almost
like
you're
managing
the
the
people
internally,
the
the
the
ftes
their
full-time
employees,
but
then
you're
also
you're,
managing
the
ether
right
like
you
have
you
it's
great
to
hear
that
there
are
a
set
of
contributors
that
you
know
you
can
see
them.
They
they
come
to
their
often
they're
in
issues
they're
in
full
request,
they're
in
discussions
right
and.
A
You'll
have
somebody
come
out
of
nowhere,
so
let's
say,
for
instance,
there's
somebody
who
you
know
they're
very
curious
about.
You
know
the
inner
workings
of
how
c
sharp
works
like
what's
a
good
place
for
them
to
start.
B
Well,
I
think,
there's
a
couple
good
places
to
start
like
if
they're
interested,
there's
two
places,
I
would
tell
people
to
definitely
go
to
these
days
like
we
have
help
wanted
issues
on
the
repo.
If
you're
looking
for
like.
How
can
I
make
some
contributions
to
rosslyn
go
to
the
roswell
repo
look
for
help
wanted
issues
like
those
we
we
try
to
flag
the
issues
that
we
feel
are
very
kind
of
like
get
people
into
the
repo
get
people
into
the
flow
of
the
code
that
we
can
help
you
get
through.
B
Your
first
pull
request
your
first
issue
and
it
it
would
be
more
about
getting
used
to
the
experience
rather
than
having
to
like
dive
into
all
the
crazy
details
of
how
things
work
also
go
to
our
discord
channel.
So
we
have
the
discord
channel
for
c-sharp
like
listed
right
on
our
readme,
and
I
tell
people
go
there
to
ask
questions,
because
both
we
have
a
huge
number,
a
pretty
significant
majority
of
the
team
who
works
on
the
c-sharp
language.
B
Experience
like
hangs
out
in
the
discord
and
regularly
answers
questions
with
community,
but
we
also
have
increasingly
those
community
members
who
are
strong
community
members
who
are
strong
contributors,
so
they
are
the
strong
contributors.
They
hang
out
there
as
well
and
they
are
very
good
at
helping
customers.
B
B
A
So
that's
great
in
the
situation
where
a
developer
wants
to
come
and
contribute
in
some
way.
That
sounds
like
a
pretty
straight
runway
as
to
contributing
right.
So,
but
what
in
the
situation-
and
I
have
this
conversation
with
folks
all
the
time-
maybe
they're
a
little
bit
too
nervous
to
write
code-
that's
going
to
you
know,
go
into
the
runtime
or
go
into
the
compiler.
A
Is
there
opportunities
for
contributions
in
say,
documentation
or
testing,
or
things
like
that
that
could,
I
guess,
be
a
little
bit
more
low
hanging
than
contributing
directly
to
the
runtime
or
some
of
the
other
pieces.
B
Yeah
absolutely
so,
we
are
always
in
need
of
better
documentation,
but
documentation
is
something
that
as
much
as
we
write,
we
can
always
write
more
and
better
documentation.
There
are
we
have
specific
labels
for
documentation
bugs
we
have
labels
for
test
bugs
and
we
even
have
sub
label
labels
for
things
like
what
we
something
we
call
like
concept
like
diagnostic
clarity,
where
it
sings
it's
like
we're,
not
asking
you
to
like
fix
a
bug,
we're
just
saying,
there's
an
error
message
that
could
be
better
like.
B
Message,
the
the
better
the
customer
is
able
to
kind
of
self-fix
their
code.
They
don't
have
to
go
to
google,
they
keep
that
interlude
going
faster
and
there
are
a
lot
of
suggestions
we've
gotten
over
the
years
of
like.
Maybe
you
could
change
the
error
message
to
be
a
little
more
expressive
or
if
it's
on
this
case,
like
just
make
it
a
little.
B
If
you
pointed
out
that,
like
it
was
off
this
identifier
instead
of
that
identifier
it'd
make
the
message
so
much
more
actionable
and
those
are
those
are
bugs
which
are
generally
like
it
is
going
into
the
product.
B
But
it
is
more
about
like
just
like
helping
the
experience
out
and
they
can
be
a
little
bit
lower
bar,
but
also,
I
would
say
that
there's
people
who
are
like
willing
to
contribute
tasks
like
be
adventurous
come
like
try
to
fix
product
bugs
we're
more
than
happy
to
help
you
kind
of
like
get
started
and
work
through
those
issues.
A
Yeah
so
again,
I
think
that's
great,
especially
for
people
that
you
know,
especially
people
that
are
new
to
contributing
in
general.
I
think
docs
is
a
great
entry
for
people
that
maybe
they
don't
have
a
ton
of
experience
contributing
to
code
in
general.
That's
on
github,
like
you,
said,
you'll,
take
any
documentation
right.
Any
anybody
that
wants
to
provide
docs
you'll
you'll
go
for
it.
I
am
curious
as
to
somebody
who
they.
A
Are
there
any
requirements
to
you
know,
do
they
need
you
know,
machine
specifications
or
they
need
some?
You
know
set
of
rules.
Is
that
documented
somewhere.
B
If
you
we
have
like
right
off
of
our
readme,
we
have
like
contributing
from
windows
contributing
from
linux,
and
that
will
kind
of
tell
you
like
what
it
is.
In
general.
We
try
to
have
as
few
requirements
as
possible
because
the
more
requirements
you
have
the
like
one
thing,
I
kind
of
like
talk
to
people
when
they're
starting
open
source
repos
is
every
requirement
you
have
is
a
bear.
It's
a
speed
bump
to
contributions.
B
It's
like
one
more
thing.
People
have
to
do,
and
it's
kind
of
enforced
that
we
actually
all
of
our
prs.
We
try
to
run
them
on
machines
that
are
just
like
blank
windows
images
so,
like
you
can
clone
our
repo
on
a
blank
windows.
Image,
build
tests,
run
all
of
our
tests
and
everything
will
work,
and
so
we
try
to
like
keep
that
bar
as
low
as
possible.
B
That
being
said,
like
most
people
use
visual
studio
to
develop
in
our
code
base,
and
we
do
have
a
very
large
solution,
so
it's
generally
like
I
can.
I
can
use
it
on
my
surface
laptop,
I'm
sorry,
my
surface
book
and
my
service
book
too.
I
can
develop
rosin
pretty
comfortably,
but
it's
a
lot
better
on
my
desktop
machine
yeah
and
then
the
second
part
you
what
you
it.
A
Was
asking
was
the
second
part
of
your
question?
It
was
just
yeah,
I
think
it
was
the
the
second
part
of
it
was
more
or
less
just
you
know.
Are
there
any
other
barriers,
like
you
mentioned
a
little
bit
about.
B
B
Yeah,
so
the
other
ones
we
have
the
other
kind
of
barriers
we
have
is
like.
We
do
have
a
pretty
like
strongly
enforced
coding
convention,
so
we
do
use
the
dotnet
the
net
code
styling.
So
it's
kind
of
the
standard
c
sharp
code
that
pretty
much
the
entire.net
team
uses.
We
have
that
code
and
we
kind
of
enforce
it
on
pull
requests,
and
so
we
have
a
we.
B
Visual
studio
style
checker
to
make
sure
everything's
you
know,
braces,
are
on
the
right
places
and
things
like
that.
For
the
most
part,
that's
if
you're
using
visual
studio,
it's
not
that
much
of
a
hassle,
because
visual
studio
will
just
format
your
code.
That
way,
as
you
type
it's
more
of,
sometimes
there
could
be
naming
conventions
with
like
camel
versus
pascal
that
people
missed
that
we
kind
of
like
will
poke
you
on
a
little
bit
in
the
code
reviews
the
only
other
kind
of
barrier
we
really
have.
B
A
B
B
B
Sharp
languages
19
buys
off
on
and
the
second
step
is
we
kind
of
tell
people
it's
like
for
anything
other
than
like
a
bug
fix
level
feature.
We,
we
really
kind
of
have
to
know
the
person
before
we'll
kind
of
accept
it,
because
we
want
to.
We
ask
the
people
if
they're,
like
hey,
I've,
never
contributed
before,
and
I
want
to
do
a
feature.
We're
like
okay
start
with
a
few
bug
fixes
like
let's
do
bug
fixes,
make
sure
that
you
are
kind
of
comfortable
with
the
lever
level
of
rigor.
B
We
require
that
you're
comfortable
the
time
investment
and
after
you've
done
a
couple
bug
fixes
and
gotten
like
a
little
bit
more
work,
and
we
cannot
get
comfortable
with
you
as
a
developer
and
then
we're
like
okay.
Now
we
have
a
good
relationship
and
we
can
kind
of
predict
like
that.
We're
going
to
be
on
the
same
page
here
with
how
these
features
go,
and
then
we
say
tell
people
like
now.
B
We
think
you're
ready
if
you
want
to
kind
of
take
on
a
feature,
we'd,
be
happy
to
help
support
you
get
into
our
schedule
and
get
things
going
and
that's
the
only
barrier
we
create,
but
we
create
that
both
to
make
sure
that
we're
using
our
time
effectively
and
that
people
kind
of
understand
like
what
are
you
signing
up
for
and
we
think
after
you've
done
a
number
of
bug
fixes,
maybe
kind
of
some
like
larger
bug,
fixes
it's
like.
Okay,
you,
you
understand
what
you're
signing
up
for
here.
You've
seen
the
scrutiny.
B
We
apply,
you've
kind
of
gotten
used
to
the
pattern
and
you
and
we
can
give
you
an
estimation
of,
like
sometimes
people
even
come
to
say
I
would
do
this
feature
we're
like
start
with
this
feature.
First,
like
that
one
is
a
huge
bite
off
like
let's
start
over
here
and
kind
of
like
work.
Your
way
up
and
in
many
ways
it's
almost
how
we
treat
it's,
how
we
treat
our
own
fpes.
B
A
A
Yeah,
I
mean
to
be
completely
honest.
It
sounds
like
you're
doing
an
incredible
job
of
fostering
people
to
want
to
contribute
right.
You
know
go
to
back
on
your
point
earlier.
It's
like
free
work,
yay,
but
the
amount
of
effort
it
takes
to
make
that
free
work.
Quality
is
substantial
right.
So
I
mean
it
sounds
to
me
like
there's
a
good,
a
good
combination
of
effort
put
in
by
you
know
the
greater.net
team
to
make
sure
the
community
is
powerful,
is
empowered
enough
to
contribute,
which
I
think
is
really
essential.
B
I
mean
it's
definitely
it's
something.
We've
always
wanted
to
be
true,
but
I
will
not
lie
and
say
that
it
was
true.
The
moment
we
started
like
there
were
some.
There
was
definitely
some
like
learning
gaps
that
we
had
when
we
started
like
one
thing.
Whenever
one
thing
I
do
a
lot
internally
is:
if
teams
existing
teams
at
microsoft,
who
have
internal
only
projects
and
they're
like
hey,
we're
going
to
move
to
github
like
I
go,
maybe
me
like
email
land
worth
we
go
and
do
a
presentation
for
them
on
like
this.
Is
these?
B
Are
the
things
you're?
Probably
not
thinking
about
when
you're
going
to
get
here?
Are
the
mistakes
we
made
and
mistakes
we
made
were
like
bad
documentation
having
all
these
internal
practices
like
one
of
the
big
mistakes
we
made
was
when
we
went
to
github,
we
did
not
have
any
documentation.
B
That
said,
don't
ju
that
told
that
kind
of
advise
people
against
just
opening
up
full
requests
with
their
favorite
linkage
feature,
and
so
people
would
like
spend
a
week
developing
this
feature
that
they
were
very
passionate
about,
and
they
put
lots
of
time
into
it,
and
then
they
would
open
a
pull
request
in
our
repo
we'd
be
like
what
are
you
doing
like?
This
is
not
how
we
do
work
here
and
we
close
it
and
they
were
like.
B
Well,
you
didn't
tell
me
not
to
do
it,
and
so
I
thought
it
was
okay,
and
it's
like.
Oh
my
god,
like
we
they're
right
like
we
way
to
do
these
things,
and
so
a
lot
of
these
things
around
that
kind
of
documentation,
bringing
people
up
the
help
wanted
issues
it's
a
lot
of.
It
is
kind
of
like
mistakes.
We've
made
along
the
way
and
like
taking
feedback
from
the
community
and
figured
out
like
how
do
we
correct?
How
do
we?
How
do
we
kind
of
make
this
work
and
be
good
for
everyone?
Yeah.
A
So
it
sounds
like
you're
doing
a
great
job,
and
I
can
only
thank
you
so
much
for
coming
on
chatting
a
little
bit
about.
You
know
the
work
that
you're
doing.
I
think
you
know
for
folks
that
want
to
get
started.
I
think
jared
you
know
laid
out
a
ton
of
options
right,
there's
help
juan
repos
there's
sub
labels
on
some
particular
issues
that
are
more
tied
to
docs
or
more
tied
to
diagnostics.
A
B
No,
I
just
say
like
definitely,
please,
you
know,
contribute
if
you
want,
if
not
just
drop
by
and
say
hello,
the
discord
is
a
fantastic
place
if
you're
just
interested
in.net,
and
you
don't
even
necessarily
want
to
contribute.
You
just
want
to
learn
more
jump
on
the
discord.
There
is
great
conversations
going
on
there
and
it
is
a
fantastic
place
to
just
kind
of
be
in
the
net
community.
Yeah.
A
In
the
end,
for
the
folks
that
are
watching
this
video,
the
discord,
the
url
is
going
to
be
in
the
project
spotlight
page
attached
to
this
video.
So
please
take
a
look
at
it
when
you
have
time
and
again
so
my
name
is
isaac
levin.
This
is
jared
parsons.
Thank
you.
So
much
for
tuning
in
to
this
iteration
of
project,
spotlight,
c-sharp.